summaryrefslogtreecommitdiff
path: root/read-cache.c
AgeCommit message (Collapse)AuthorFilesLines
2015-06-25Merge branch 'jk/diagnose-config-mmap-failure' into maintLibravatar Junio C Hamano1-1/+1
The configuration reader/writer uses mmap(2) interface to access the files; when we find a directory, it barfed with "Out of memory?". * jk/diagnose-config-mmap-failure: xmmap(): drop "Out of memory?" config.c: rewrite ENODEV into EISDIR when mmap fails config.c: avoid xmmap error messages config.c: fix mmap leak when writing config read-cache.c: drop PROT_WRITE from mmap of index
2015-05-28read-cache.c: drop PROT_WRITE from mmap of indexLibravatar Jeff King1-1/+1
Once upon a time, git's in-memory representation of a cache entry actually pointed to the mmap'd on-disk data. So in 520fc24 (Allow writing to the private index file mapping., 2005-04-26), we specified PROT_WRITE so that we could tweak the entries while we run (in our own MAP_PRIVATE copy-on-write version, of course). Later, 7a51ed6 (Make on-disk index representation separate from in-core one, 2008-01-14) stopped doing this; we copy the data into our in-core representation, and then drop the mmap immediately. We can therefore drop the PROT_WRITE flag. It's probably not hurting anything as it is, but it's potentially confusing. Note that we could also mark the mapping as "const" to verify that we never write to it. However, we don't typically do that for our other maps, as it then requires casting to munmap() it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-27Merge branch 'sb/leaks'Libravatar Junio C Hamano1-10/+12
* sb/leaks: http: release the memory of a http pack request as well read-cache: fix memleak add_to_index(): free unused cache-entry commit.c: fix a memory leak http-push: remove unneeded cleanup merge-recursive: fix memleaks merge-blobs.c: fix a memleak builtin/apply.c: fix a memleak update-index: fix a memleak read-cache: free cache entry in add_to_index in case of early return
2015-03-25Merge branch 'tg/fix-check-order-with-split-index'Libravatar Junio C Hamano1-19/+23
The split-index mode introduced at v2.3.0-rc0~41 was broken in the codepath to protect us against a broken reimplementation of Git that writes an invalid index with duplicated index entries, etc. * tg/fix-check-order-with-split-index: read-cache: fix reading of split index
2015-03-23read-cache: fix memleakLibravatar Stefan Beller1-5/+2
`ce` is allocated in make_cache_entry and should be freed if it is not used any more. refresh_cache_entry as a wrapper around refresh_cache_ent will either return - the `ce` given as the parameter, when it was up-to-date; - a new updated cache entry which is allocated to new memory; or - a NULL when refreshing failed. In the latter two cases, the original cache-entry `ce` is not used and needs to be freed. The rule can be expressed as "if the return value from refresh is different from the original ce, ce is no longer used." Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-23add_to_index(): free unused cache-entryLibravatar Junio C Hamano1-3/+5
We allocate a cache-entry pretty early in the function and then decide either not to do anything when we are pretending to add, or add it and then get an error (another possibility is obviously to succeed). When pretending or failing to add, we forgot to free the cache-entry. Noticed during a discussion on Stefan's patch to change the coding style without fixing the issue ;-) Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-22read-cache: free cache entry in add_to_index in case of early returnLibravatar Stefan Beller1-2/+5
This frees `ce` would be leaking in the error path. Additionally a free is moved towards the return. This helps code readability as we often have this pattern of freeing resources just before return/exit and not in between the code. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20read-cache: fix reading of split indexLibravatar Thomas Gummerer1-19/+23
The split index extension uses ewah bitmaps to mark index entries as deleted, instead of removing them from the index directly. This can result in an on-disk index, in which entries of stage #0 and higher stages appear, which are removed later when the index bases are merged. 15999d0 read_index_from(): catch out of order entries when reading an index file introduces a check which checks if the entries are in order after each index entry is read in do_read_index. This check may however fail when a split index is read. Fix this by moving checking the index after we know there is no split index or after the split index bases are successfully merged instead. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-25Merge branch 'sb/plug-leak-in-make-cache-entry'Libravatar Junio C Hamano1-2/+8
"update-index --refresh" used to leak when an entry cannot be refreshed for whatever reason. * sb/plug-leak-in-make-cache-entry: read-cache.c: free cache entry when refreshing fails
2015-02-17read-cache.c: free cache entry when refreshing failsLibravatar Stefan Beller1-2/+8
This fixes a memory leak when building the cache entries as refresh_cache_entry may decide to return NULL, but it does not free the cache entry structure which was passed in as an argument. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-17Sync with v2.1.4Libravatar Junio C Hamano1-2/+8
* maint-2.1: Git 2.1.4 Git 2.0.5 Git 1.9.5 Git 1.8.5.6 fsck: complain about NTFS ".git" aliases in trees read-cache: optionally disallow NTFS .git variants path: add is_ntfs_dotgit() helper fsck: complain about HFS+ ".git" aliases in trees read-cache: optionally disallow HFS+ .git variants utf8: add is_hfs_dotgit() helper fsck: notice .git case-insensitively t1450: refactor ".", "..", and ".git" fsck tests verify_dotfile(): reject .git case-insensitively read-tree: add tests for confusing paths like ".." and ".git" unpack-trees: propagate errors adding entries to the index
2014-12-17Sync with v2.0.5Libravatar Junio C Hamano1-2/+8
* maint-2.0: Git 2.0.5 Git 1.9.5 Git 1.8.5.6 fsck: complain about NTFS ".git" aliases in trees read-cache: optionally disallow NTFS .git variants path: add is_ntfs_dotgit() helper fsck: complain about HFS+ ".git" aliases in trees read-cache: optionally disallow HFS+ .git variants utf8: add is_hfs_dotgit() helper fsck: notice .git case-insensitively t1450: refactor ".", "..", and ".git" fsck tests verify_dotfile(): reject .git case-insensitively read-tree: add tests for confusing paths like ".." and ".git" unpack-trees: propagate errors adding entries to the index
2014-12-17Sync with v1.9.5Libravatar Junio C Hamano1-2/+8
* maint-1.9: Git 1.9.5 Git 1.8.5.6 fsck: complain about NTFS ".git" aliases in trees read-cache: optionally disallow NTFS .git variants path: add is_ntfs_dotgit() helper fsck: complain about HFS+ ".git" aliases in trees read-cache: optionally disallow HFS+ .git variants utf8: add is_hfs_dotgit() helper fsck: notice .git case-insensitively t1450: refactor ".", "..", and ".git" fsck tests verify_dotfile(): reject .git case-insensitively read-tree: add tests for confusing paths like ".." and ".git" unpack-trees: propagate errors adding entries to the index
2014-12-17Sync with v1.8.5.6Libravatar Junio C Hamano1-2/+8
* maint-1.8.5: Git 1.8.5.6 fsck: complain about NTFS ".git" aliases in trees read-cache: optionally disallow NTFS .git variants path: add is_ntfs_dotgit() helper fsck: complain about HFS+ ".git" aliases in trees read-cache: optionally disallow HFS+ .git variants utf8: add is_hfs_dotgit() helper fsck: notice .git case-insensitively t1450: refactor ".", "..", and ".git" fsck tests verify_dotfile(): reject .git case-insensitively read-tree: add tests for confusing paths like ".." and ".git" unpack-trees: propagate errors adding entries to the index
2014-12-17read-cache: optionally disallow NTFS .git variantsLibravatar Johannes Schindelin1-0/+2
The point of disallowing ".git" in the index is that we would never want to accidentally overwrite files in the repository directory. But this means we need to respect the filesystem's idea of when two paths are equal. The prior commit added a helper to make such a comparison for NTFS and FAT32; let's use it in verify_path(). We make this check optional for two reasons: 1. It restricts the set of allowable filenames, which is unnecessary for people who are not on NTFS nor FAT32. In practice this probably doesn't matter, though, as the restricted names are rather obscure and almost certainly would never come up in practice. 2. It has a minor performance penalty for every path we insert into the index. This patch ties the check to the core.protectNTFS config option. Though this is expected to be most useful on Windows, we allow it to be set everywhere, as NTFS may be mounted on other platforms. The variable does default to on for Windows, though. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-17read-cache: optionally disallow HFS+ .git variantsLibravatar Jeff King1-0/+3
The point of disallowing ".git" in the index is that we would never want to accidentally overwrite files in the repository directory. But this means we need to respect the filesystem's idea of when two paths are equal. The prior commit added a helper to make such a comparison for HFS+; let's use it in verify_path. We make this check optional for two reasons: 1. It restricts the set of allowable filenames, which is unnecessary for people who are not on HFS+. In practice this probably doesn't matter, though, as the restricted names are rather obscure and almost certainly would never come up in practice. 2. It has a minor performance penalty for every path we insert into the index. This patch ties the check to the core.protectHFS config option. Though this is expected to be most useful on OS X, we allow it to be set everywhere, as HFS+ may be mounted on other platforms. The variable does default to on for OS X, though. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-17verify_dotfile(): reject .git case-insensitivelyLibravatar Jeff King1-2/+3
We do not allow ".git" to enter into the index as a path component, because checking out the result to the working tree may causes confusion for subsequent git commands. However, on case-insensitive file systems, ".Git" or ".GIT" is the same. We should catch and prevent those, too. Note that technically we could allow this for repos on case-sensitive filesystems. But there's not much point. It's unlikely that anybody cares, and it creates a repository that is unexpectedly non-portable to other systems. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01lockfile.h: extract new header file for the functions in lockfile.cLibravatar Michael Haggerty1-0/+1
Move the interface declaration for the functions in lockfile.c from cache.h to a new file, lockfile.h. Add #includes where necessary (and remove some redundant includes of cache.h by files that already include builtin.h). Move the documentation of the lock_file state diagram from lockfile.c to the new header file. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01hold_locked_index(): move from lockfile.c to read-cache.cLibravatar Michael Haggerty1-0/+8
lockfile.c contains the general API for locking any file. Code specifically about the index file doesn't belong here. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01commit_lock_file_to(): refactor a helper out of commit_lock_file()Libravatar Michael Haggerty1-10/+3
commit_locked_index(), when writing to an alternate index file, duplicates (poorly) the code in commit_lock_file(). And anyway, it shouldn't have to know so much about the internal workings of lockfile objects. So extract a new function commit_lock_file_to() that does the work common to the two functions, and call it from both commit_lock_file() and commit_locked_index(). Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01lockfile: change lock_file::filename into a strbufLibravatar Michael Haggerty1-2/+2
For now, we still make sure to allocate at least PATH_MAX characters for the strbuf because resolve_symlink() doesn't know how to expand the space for its return value. (That will be fixed in a moment.) Another alternative would be to just use a strbuf as scratch space in lock_file() but then store a pointer to the naked string in struct lock_file. But lock_file objects are often reused. By reusing the same strbuf, we can avoid having to reallocate the string most times when a lock_file object is reused. Helped-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01lockfile: avoid transitory invalid statesLibravatar Michael Haggerty1-0/+1
Because remove_lock_file() can be called any time by the signal handler, it is important that any lock_file objects that are in the lock_file_list are always in a valid state. And since lock_file objects are often reused (but are never removed from lock_file_list), that means we have to be careful whenever mutating a lock_file object to always keep it in a well-defined state. This was formerly not the case, because part of the state was encoded by setting lk->filename to the empty string vs. a valid filename. It is wrong to assume that this string can be updated atomically; for example, even strcpy(lk->filename, value) is unsafe. But the old code was even more reckless; for example, strcpy(lk->filename, path); if (!(flags & LOCK_NODEREF)) resolve_symlink(lk->filename, max_path_len); strcat(lk->filename, ".lock"); During the call to resolve_symlink(), lk->filename contained the name of the file that was being locked, not the name of the lockfile. If a signal were raised during that interval, then the signal handler would have deleted the valuable file! We could probably continue to use the filename field to encode the state by being careful to write characters 1..N-1 of the filename first, and then overwrite the NUL at filename[0] with the first character of the filename, but that would be awkward and error-prone. So, instead of using the filename field to determine whether the lock_file object is active, add a new field "lock_file::active" for this purpose. Be careful to set this field only when filename really contains the name of a file that should be deleted on cleanup. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01close_lock_file(): exit (successfully) if file is already closedLibravatar Michael Haggerty1-1/+1
Suggested-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-19Merge branch 'rs/refresh-beyond-symlink' into maintLibravatar Junio C Hamano1-0/+8
* rs/refresh-beyond-symlink: read-cache: check for leading symlinks when refreshing index
2014-09-19Merge branch 'jp/index-with-corrupt-stages'Libravatar Junio C Hamano1-1/+18
A broken reimplementation of Git could write an invalid index that records both stage #0 and higher stage entries for the same path. Notice and reject such an index, as there is no sensible fallback (we do not know if the broken tool wanted to resolve and forgot to remove higher stage entries, or if it wanted to unresolve and forgot to remove the stage#0 entry). * jp/index-with-corrupt-stages: read_index_unmerged(): remove unnecessary loop index adjustment read_index_from(): catch out of order entries when reading an index file
2014-09-11Merge branch 'ta/config-set-2'Libravatar Junio C Hamano1-11/+3
Update git_config() users with callback functions for a very narrow scope with calls to config-set API that lets us query a single variable. * ta/config-set-2: builtin/apply.c: replace `git_config()` with `git_config_get_string_const()` merge-recursive.c: replace `git_config()` with `git_config_get_int()` ll-merge.c: refactor `read_merge_config()` to use `git_config_string()` fast-import.c: replace `git_config()` with `git_config_get_*()` family branch.c: replace `git_config()` with `git_config_get_string() alias.c: replace `git_config()` with `git_config_get_string()` imap-send.c: replace `git_config()` with `git_config_get_*()` family pager.c: replace `git_config()` with `git_config_get_value()` builtin/gc.c: replace `git_config()` with `git_config_get_*()` family rerere.c: replace `git_config()` with `git_config_get_*()` family fetchpack.c: replace `git_config()` with `git_config_get_*()` family archive.c: replace `git_config()` with `git_config_get_bool()` family read-cache.c: replace `git_config()` with `git_config_get_*()` family http-backend.c: replace `git_config()` with `git_config_get_bool()` family daemon.c: replace `git_config()` with `git_config_get_bool()` family
2014-09-09Merge branch 'rs/refresh-beyond-symlink'Libravatar Junio C Hamano1-0/+8
"git add x" where x that used to be a directory has become a symbolic link to a directory misbehaved. * rs/refresh-beyond-symlink: read-cache: check for leading symlinks when refreshing index
2014-08-29read_index_unmerged(): remove unnecessary loop index adjustmentLibravatar Jaime Soriano Pastor1-1/+0
Signed-off-by: Jaime Soriano Pastor <jsorianopastor@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-29read_index_from(): catch out of order entries when reading an index fileLibravatar Jaime Soriano Pastor1-0/+18
Signed-off-by: Jaime Soriano Pastor <jsorianopastor@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-10read-cache: check for leading symlinks when refreshing indexLibravatar René Scharfe1-0/+8
Don't add paths with leading symlinks to the index while refreshing; we only track those symlinks themselves. We already ignore them while preloading (see read_index_preload.c). Reported-by: Nikolay Avdeev <avdeev@math.vsu.ru> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-07read-cache.c: replace `git_config()` with `git_config_get_*()` familyLibravatar Tanay Abhra1-11/+3
Use `git_config_get_*()` family instead of `git_config()` to take advantage of the config-set API which provides a cleaner control flow. Use an intermediate value, as `version` can not be used directly in git_config_get_int() due to incompatible type. Signed-off-by: Tanay Abhra <tanayabh@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-16Merge branch 'nd/split-index'Libravatar Junio C Hamano1-28/+244
An experiment to use two files (the base file and incremental changes relative to it) to represent the index to reduce I/O cost of rewriting a large index when only small part of the working tree changes. * nd/split-index: (32 commits) t1700: new tests for split-index mode t2104: make sure split index mode is off for the version test read-cache: force split index mode with GIT_TEST_SPLIT_INDEX read-tree: note about dropping split-index mode or index version read-tree: force split-index mode off on --index-output rev-parse: add --shared-index-path to get shared index path update-index --split-index: do not split if $GIT_DIR is read only update-index: new options to enable/disable split index mode split-index: strip pathname of on-disk replaced entries split-index: do not invalidate cache-tree at read time split-index: the reading part split-index: the writing part read-cache: mark updated entries for split index read-cache: save deleted entries in split index read-cache: mark new entries for split index read-cache: split-index mode read-cache: save index SHA-1 after reading entry.c: update cache_changed if refresh_cache is set in checkout_entry() cache-tree: mark istate->cache_changed on prime_cache_tree() cache-tree: mark istate->cache_changed on cache tree update ...
2014-06-25Merge branch 'ym/fix-opportunistic-index-update-race' into maintLibravatar Junio C Hamano1-1/+46
"git status", even though it is a read-only operation, tries to update the index with refreshed lstat(2) info to optimize future accesses to the working tree opportunistically, but this could race with a "read-write" operation that modify the index while it is running. Detect such a race and avoid overwriting the index. * ym/fix-opportunistic-index-update-race: read-cache.c: verify index file before we opportunistically update it wrapper.c: add xpread() similar to xread()
2014-06-20cleanup duplicate name_compare() functionsLibravatar Jeremiah Mahler1-10/+13
We often represent our strings as a counted string, i.e. a pair of the pointer to the beginning of the string and its length, and the string may not be NUL terminated to that length. To compare a pair of such counted strings, unpack-trees.c and read-cache.c implement their own name_compare() functions identically. In addition, the cache_name_compare() function in read-cache.c is nearly identical. The only difference is when one string is the prefix of the other string, in which case name_compare() returns -1/+1 to show which one is longer, and cache_name_compare() returns the difference of the lengths to show the same information. Unify these three functions by using the implementation from cache_name_compare(). This does not make any difference to the existing and future callers, as they must be paying attention only to the sign of the returned value (and not the magnitude) because the original implementations of these two functions return values returned by memcmp(3) when the one string is not a prefix of the other string, and the only thing memcmp(3) guarantees its callers is the sign of the returned value, not the magnitude. Signed-off-by: Jeremiah Mahler <jmmahler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13t1700: new tests for split-index modeLibravatar Nguyễn Thái Ngọc Duy1-2/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13read-cache: force split index mode with GIT_TEST_SPLIT_INDEXLibravatar Nguyễn Thái Ngọc Duy1-1/+9
This could be used to run the whole test suite with split indexes. Index splitting is carried out at random. "git read-tree" also resets the index and forces splitting at the next update. I had a lot of headaches with the test suite, which proves it exercises split index pretty good. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13read-tree: force split-index mode off on --index-outputLibravatar Nguyễn Thái Ngọc Duy1-1/+2
Just a (paranoid?) safety measure.. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13update-index --split-index: do not split if $GIT_DIR is read onlyLibravatar Nguyễn Thái Ngọc Duy1-3/+10
If $GIT_DIR is read only, we can't write $GIT_DIR/sharedindex. This could happen when $GIT_INDEX_FILE is set to somehwere outside $GIT_DIR. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13update-index: new options to enable/disable split index modeLibravatar Nguyễn Thái Ngọc Duy1-6/+61
If you have a large work tree but only make changes in a subset, then $GIT_DIR/index's size should be stable after a while. If you change branches that touch something else, $GIT_DIR/index's size may grow large that it becomes as slow as the unified index. Do --split-index again occasionally to force all changes back to the shared index and keep $GIT_DIR/index small. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13split-index: strip pathname of on-disk replaced entriesLibravatar Nguyễn Thái Ngọc Duy1-0/+10
We know the positions of replaced entries via the replace bitmap in "link" extension, so the "name" path does not have to be stored (it's still in the shared index). With this, we also have a way to distinguish additions vs replacements at load time and can catch broken "link" extensions. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13split-index: do not invalidate cache-tree at read timeLibravatar Nguyễn Thái Ngọc Duy1-1/+2
We are sure that after merge_base_index() is done. cache-tree can still be used with the final index. So don't destroy cache tree. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13split-index: the reading partLibravatar Nguyễn Thái Ngọc Duy1-2/+0
CE_REMOVE'd entries are removed here because only parts of the code base (unpack_trees in fact) test this bit when they look for the presence of an entry. Leaving them may confuse the code ignores this bit and expects to see a real entry. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13read-cache: mark updated entries for split indexLibravatar Nguyễn Thái Ngọc Duy1-1/+4
The large part of this patch just follows CE_ENTRY_CHANGED marks. replace_index_entry() is updated to update split_index->base->cache[] as well so base->cache[] does not reference to a freed entry. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13read-cache: save deleted entries in split indexLibravatar Nguyễn Thái Ngọc Duy1-6/+8
Entries that belong to the base index should not be freed. Mark CE_REMOVE to track them. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13read-cache: mark new entries for split indexLibravatar Nguyễn Thái Ngọc Duy1-1/+2
Make sure entry addition does not lead to unifying the index. We don't need to explicitly keep track of new entries. If ce->index is zero, they're new. Otherwise it's unlikely that they are new, but we'll do a thorough check later at writing time. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13read-cache: split-index modeLibravatar Nguyễn Thái Ngọc Duy1-5/+91
This split-index mode is designed to keep write cost proportional to the number of changes the user has made, not the size of the work tree. (Read cost is another matter, to be dealt separately.) This mode stores index info in a pair of $GIT_DIR/index and $GIT_DIR/sharedindex.<SHA-1>. sharedindex is large and unchanged over time while "index" is smaller and updated often. Format details are in index-format.txt, although not everything is implemented in this patch. Shared indexes are not automatically removed, because it's unclear if the shared index is needed by any (even temporary) indexes by just looking at it. After a while you'll collect stale shared indexes. The good news is one shared index is useable for long, until $GIT_DIR/index becomes too big and sluggish that the new shared index must be created. The safest way to clean shared indexes is to turn off split index mode, so shared files are all garbage, delete them all, then turn on split index mode again. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13read-cache: save index SHA-1 after readingLibravatar Nguyễn Thái Ngọc Duy1-2/+4
Also update SHA-1 after writing. If we do not do that, the second read_index() will see "initialized" variable already set and not read .git/index again, which is fine, except istate->sha1 now has a stale value. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13cache-tree: mark istate->cache_changed on cache tree invalidationLibravatar Nguyễn Thái Ngọc Duy1-3/+3
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13read-cache: be specific what part of the index has changedLibravatar Nguyễn Thái Ngọc Duy1-5/+6
cache entry additions, removals and modifications are separated out. The rest of changes are still in the catch-all flag SOMETHING_CHANGED, which would be more specific later. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13read-cache: be strict about "changed" in remove_marked_cache_entries()Libravatar Nguyễn Thái Ngọc Duy1-0/+2
remove_marked_cache_entries() deletes entries marked with CE_REMOVE. But if there is no such entry, do not mark the index as "changed" because that could trigger an index update unnecessarily. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>