git/read-cache.c, branch v2.37.2

Merge branch 'tk/untracked-cache-with-uall' into maint

2022-08-11T04:52:34Z

Fix for a bug that makes write-tree to fail to write out a non-existent index as a tree, introduced in 2.37. source: <20220722212232.833188-1-martin.agren@gmail.com> * tk/untracked-cache-with-uall: read-cache: make `do_read_index()` always set up `istate->repo`

read-cache: make `do_read_index()` always set up `istate->repo`

2022-07-22T21:51:00Z

If there is no index file, e.g., because the repository has just been created, we return zero early (unless `must_exist` makes us die instead.) This early return means we do not set up `istate->repo`. With `core.untrackedCache=true`, the recent e6a653554b ("untracked-cache: support '--untracked-files=all' if configured", 2022-03-31) will eventually pass down `istate->repo` as a null pointer to `repo_config_get_string()`, causing a segmentation fault. If we do hit this early return, set up `istate->repo` similar to when we actually read the index. Reported-by: Joey Hess Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano

read_index_from(): avoid memory leak

2022-06-16T20:22:03Z

In 998330ac2e7c (read-cache: look for shared index files next to the index, too, 2021-08-26), we added code that allocates memory to store the base path of a shared index, but we never released that memory. Reported by Coverity. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'zh/read-cache-copy-name-entry-fix'

2022-06-13T22:53:43Z

Remove redundant copying (with index v3 and older) or possible over-reading beyond end of mmapped memory (with index v4) has been corrected. * zh/read-cache-copy-name-entry-fix: read-cache.c: reduce unnecessary cache entry name copying

read-cache.c: reduce unnecessary cache entry name copying

2022-06-06T17:37:06Z

575fa8a3 (read-cache: read data in a hash-independent way, 2019-02-19) added a new code to copy from the on-disk data into the name member of the in-core cache entry, which is already done immediately after that in a way that takes prefix-compression into account. Remove this code, as it is not just unnecessary, but also can be reading beyond the on-disk data, when we are copying very long prefix string from the previous entry. Signed-off-by: ZheNing Hu [jc: rewrote the log message with Réne's findings] Signed-off-by: Junio C Hamano

Merge branch 'ds/sparse-sparse-checkout'

2022-06-03T21:30:35Z

"sparse-checkout" learns to work well with the sparse-index feature. * ds/sparse-sparse-checkout: sparse-checkout: integrate with sparse index p2000: add test for 'git sparse-checkout [add|set]' sparse-index: complete partial expansion sparse-index: partially expand directories sparse-checkout: --no-sparse-index needs a full index cache-tree: implement cache_tree_find_path() sparse-index: introduce partially-sparse indexes sparse-index: create expand_index() t1092: stress test 'git sparse-checkout set' t1092: refactor 'sparse-index contents' test

sparse-index: introduce partially-sparse indexes

2022-05-23T18:08:21Z

A future change will present a temporary, in-memory mode where the index can both contain sparse directory entries but also not be completely collapsed to the smallest possible sparse directories. This will be necessary for modifying the sparse-checkout definition while using a sparse index. For now, convert the single-bit member 'sparse_index' in 'struct index_state' to be a an 'enum sparse_index_mode' with three modes: * INDEX_EXPANDED (0): No sparse directories exist. This is always the case for repositories that do not use cone-mode sparse-checkout. * INDEX_COLLAPSED: Sparse directories may exist. Files outside the sparse-checkout cone are reduced to sparse directory entries whenever possible. * INDEX_PARTIALLY_SPARSE: Sparse directories may exist. Some file entries outside the sparse-checkout cone may exist. Running convert_to_sparse() may further reduce those files to sparse directory entries. The main reason to store this extra information is to allow convert_to_sparse() to short-circuit when the index is already in INDEX_EXPANDED mode but to actually do the necessary work when in INDEX_PARTIALLY_SPARSE mode. The INDEX_PARTIALLY_SPARSE mode will be used in an upcoming change. Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

read-cache: set sparsity when index is new

2022-05-10T23:45:12Z

When the index read in 'do_read_index()' does not exist on-disk, mark the index "sparse" if the executing command does not require a full index and sparse index is otherwise enabled. Some commands (such as 'git stash -u') implicitly create a new index (when the 'GIT_INDEX_FILE' variable points to a non-existent file) and perform some operation on it. However, when this index is created, it isn't created with the same sparsity settings as the repo index. As a result, while these indexes may be sparse during the operation, they are always expanded before being written to disk. We can avoid that expansion by defaulting the index to "sparse", in which case it will only be expanded if the full index is needed. Note that the function 'set_new_index_sparsity()' is created despite having only a single caller because additional callers will be added in a subsequent patch. Signed-off-by: Victoria Dye Signed-off-by: Junio C Hamano

Merge branch 'vd/mv-refresh-stat'

2022-04-04T17:56:24Z

"git mv" failed to refresh the cached stat information for the entry it moved. * vd/mv-refresh-stat: mv: refresh stat info for moved entry

mv: refresh stat info for moved entry

2022-03-29T16:45:02Z

Update the stat info of the moved index entry in 'rename_index_entry_at()' if the entry is up-to-date with the index. Internally, 'git mv' uses 'rename_index_entry_at()' to move the source index entry to the destination. However, it directly copies the stat info of the original cache entry, which will not reflect the 'ctime' of the file renaming operation that happened as part of the move. If a file is otherwise up-to-date with the index, that difference in 'ctime' will make the entry appear out-of-date until the next index-refreshing operation (e.g., 'git status'). Some commands, such as 'git reset', use the cached stat information to determine whether a file is up-to-date; if this information is incorrect, the command will fail when it should pass. In order to ensure a moved entry is evaluated as 'up-to-date' when appropriate, refresh the destination index entry's stat info in 'git mv' if and only if the file is up-to-date. Note that the test added in 't7001-mv.sh' requires a "sleep 1" to ensure the 'ctime' of the file creation will be definitively older than the 'ctime' of the renamed file in 'git mv'. Reported-by: Maximilian Reichel Signed-off-by: Victoria Dye Signed-off-by: Junio C Hamano