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

Merge branch 'nd/untracked-cache'

2015-06-24T19:21:49Z

Hotfix for the 'untracked-cache' topic that is already in 'master'. * nd/untracked-cache: read-cache: fix untracked cache invalidation when split-index is used

Merge branch 'jk/diagnose-config-mmap-failure'

2015-06-11T16:29:55Z

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

read-cache: fix untracked cache invalidation when split-index is used

2015-06-08T16:45:19Z

Before this change, t7063.17 fails. The actual action though happens at t7063.16 where the entry "two" is added back to index after being removed in the .13. Here we expect a directory invalidate at .16 and none at .17 where untracked cache is refreshed. But things do not go as expected when GIT_TEST_SPLIT_INDEX is set. The different behavior that happens at .16 when split index is used: the entry "two", when deleted at .13, is simply marked "deleted". When .16 executes, the entry resurfaces from the version in base index. This happens in merge_base_index() where add_index_entry() is called to add "two" back from the base index. This is where the bug comes from. The add_index_entry() is called with ADD_CACHE_KEEP_CACHE_TREE flag because this version of "two" is not new, it does not break either cache-tree or untracked cache. The code should check this flag and not invalidate untracked cache. This causes a second invalidation violates test expectation. The fix is obvious. Noticed-by: Thomas Gummerer Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

read-cache.c: drop PROT_WRITE from mmap of index

2015-05-28T18:32:04Z

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 Signed-off-by: Junio C Hamano

Merge branch 'nd/untracked-cache'

2015-05-26T20:24:46Z

Teach the index to optionally remember already seen untracked files to speed up "git status" in a working tree with tons of cruft. * nd/untracked-cache: (24 commits) git-status.txt: advertisement for untracked cache untracked cache: guard and disable on system changes mingw32: add uname() t7063: tests for untracked cache update-index: test the system before enabling untracked cache update-index: manually enable or disable untracked cache status: enable untracked cache untracked-cache: temporarily disable with $GIT_DISABLE_UNTRACKED_CACHE untracked cache: mark index dirty if untracked cache is updated untracked cache: print stats with $GIT_TRACE_UNTRACKED_STATS untracked cache: avoid racy timestamps read-cache.c: split racy stat test to a separate function untracked cache: invalidate at index addition or removal untracked cache: load from UNTR index extension untracked cache: save to an index extension ewah: add convenient wrapper ewah_serialize_strbuf() untracked cache: don't open non-existent .gitignore untracked cache: mark what dirs should be recursed/saved untracked cache: record/validate dir mtime and reuse cached output untracked cache: make a wrapper around {open,read,close}dir() ...

Merge branch 'sb/leaks'

2015-03-27T20:02:32Z

* 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

Merge branch 'tg/fix-check-order-with-split-index'

2015-03-25T19:54:26Z

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

read-cache: fix memleak

2015-03-23T18:12:59Z

`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 Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

add_to_index(): free unused cache-entry

2015-03-23T18:12:59Z

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

read-cache: free cache entry in add_to_index in case of early return

2015-03-22T19:11:25Z

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 Signed-off-by: Junio C Hamano