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

lockfile.h: extract new header file for the functions in lockfile.c

2014-10-01T20:56:14Z

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

hold_locked_index(): move from lockfile.c to read-cache.c

2014-10-01T20:54:31Z

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

commit_lock_file_to(): refactor a helper out of commit_lock_file()

2014-10-01T20:52:06Z

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

lockfile: change lock_file::filename into a strbuf

2014-10-01T20:50:01Z

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

lockfile: avoid transitory invalid states

2014-10-01T20:48:59Z

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

close_lock_file(): exit (successfully) if file is already closed

2014-10-01T20:38:39Z

Suggested-by: Jonathan Nieder Signed-off-by: Michael Haggerty Signed-off-by: Junio C Hamano

Merge branch 'jp/index-with-corrupt-stages'

2014-09-19T18:38:34Z

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

Merge branch 'ta/config-set-2'

2014-09-11T17:33:26Z

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

Merge branch 'rs/refresh-beyond-symlink'

2014-09-09T19:54:01Z

"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

read_index_unmerged(): remove unnecessary loop index adjustment

2014-08-29T17:05:53Z

Signed-off-by: Jaime Soriano Pastor Signed-off-by: Junio C Hamano