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

Merge branch 'dt/name-hash-dir-entry-fix' into maint

2015-11-03T23:32:40Z

The name-hash subsystem that is used to cope with case insensitive filesystems keeps track of directories and their on-filesystem cases for all the paths in the index by holding a pointer to a randomly chosen cache entry that is inside the directory (for its ce->ce_name component). This pointer was not updated even when the cache entry was removed from the index, leading to use after free. This was fixed by recording the path for each directory instead of borrowing cache entries and restructuring the API somewhat. * dt/name-hash-dir-entry-fix: name-hash: don't reuse cache_entry in dir_entry

name-hash: don't reuse cache_entry in dir_entry

2015-10-21T19:47:38Z

Stop reusing cache_entry in dir_entry; doing so causes a use-after-free bug. During merges, we free entries that we no longer need in the destination index. But those entries might have also been stored in the dir_entry cache, and when a later call to add_to_index found them, they would be used after being freed. To prevent this, change dir_entry to store a copy of the name instead of a pointer to a cache_entry. This entails some refactoring of code that expects the cache_entry. Keith McGuigan diagnosed this bug and wrote the initial patch, but this version does not use any of Keith's code. Helped-by: Keith McGuigan Helped-by: Junio C Hamano Signed-off-by: David Turner Signed-off-by: Junio C Hamano

read-cache: fix indentation in read_index_from

2015-08-31T19:31:00Z

Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

Merge branch 'mh/tempfile'

2015-08-25T21:57:09Z

The "lockfile" API has been rebuilt on top of a new "tempfile" API. * mh/tempfile: credential-cache--daemon: use tempfile module credential-cache--daemon: delete socket from main() gc: use tempfile module to handle gc.pid file lock_repo_for_gc(): compute the path to "gc.pid" only once diff: use tempfile module setup_temporary_shallow(): use tempfile module write_shared_index(): use tempfile module register_tempfile(): new function to handle an existing temporary file tempfile: add several functions for creating temporary files prepare_tempfile_object(): new function, extracted from create_tempfile() tempfile: a new module for handling temporary files commit_lock_file(): use get_locked_file_path() lockfile: add accessor get_lock_file_path() lockfile: add accessors get_lock_file_fd() and get_lock_file_fp() create_bundle(): duplicate file descriptor to avoid closing it twice lockfile: move documentation to lockfile.h and lockfile.c

write_shared_index(): use tempfile module

2015-08-10T19:57:14Z

Signed-off-by: Michael Haggerty Signed-off-by: Junio C Hamano

lockfile: add accessors get_lock_file_fd() and get_lock_file_fp()

2015-08-10T19:57:14Z

We are about to move those members, so change client code to read them through accessor functions. Signed-off-by: Michael Haggerty Signed-off-by: Junio C Hamano

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