I've had this patch series kicking around for a long time, along with some followup patches to fix a race in reference deletion. I haven't had the time to get everything done and tested, but let me at least push this first series out there. I especially want to submit it in case we accept a GSoC student for the project "Refactor tempfile handling", because (1) I don't want me and the student to be stepping on each others' toes, and (2) there are some cleanups and documentation improvements here that will hopefully be useful to the student. The first patch actually demonstrates the race condition that I hope to fix someday. The last patch introduces the lockfile feature that I think is needed to fix it: the ability to activate a packed-refs file while still holding the lock to prevent another process from overwriting it before the accompanying loose reference updates are all finished. But the fix itself is not included here, so you might want to keep the last patch on hold until there is a concrete user of the feature. The rest of the patches hopefully make the lockfile API more consistent and better documented. There were a lot of situations when a failure in one step of the lock/commit procedure left a lock in an ill-defined state. That's probably not a problem very often in practice, because we tend to die() soon after any locking problems. But it is still helpful for lockfile objects to have a well-defined state diagram (especially if your goal is to add a new feature to them!) Several patches are also devoted to making lock filename handling use strbufs (for the usual reasons), and reducing the need for callers to reach into the "filename" field and especially for them to use that field as temporary scratch space. Michael Michael Haggerty (22): t3204: test deleting references when lock files already exist try_merge_strategy(): remove redundant lock_file allocation rollback_lock_file(): do not clear filename redundantly rollback_lock_file(): set fd to -1 lockfile: unlock file if lockfile permissions cannot be adjusted hold_lock_file_for_append(): release lock on errors lock_file(): always add lock_file object to lock_file_list struct lock_file: replace on_list field with flags field api-lockfile: expand the documentation lockfile.c: document the various states of lock_file objects lockfile: define a constant LOCK_SUFFIX_LEN delete_ref_loose(): don't muck around in the lock_file's filename config: change write_error() to take a (struct lock_file *) argument lockfile: use strbufs when handling (most) paths resolve_symlink(): use a strbuf internally commit_lock_file(): don't work with a fixed-length buffer lock_file(): exit early if lockfile cannot be opened lockfile: also keep track of the filename of the file being locked struct lock_file: rename lock_filename field to staging_filename remove_lock_file(): call rollback_lock_file() lockfile: extract a function reset_lock_file() lockfile: allow new file contents to be written while retaining lock Documentation/technical/api-lockfile.txt | 90 +++++-- builtin/commit.c | 12 +- builtin/merge.c | 1 - builtin/reflog.c | 2 +- cache.h | 9 +- config.c | 11 +- lockfile.c | 389 +++++++++++++++++++++---------- refs.c | 8 +- shallow.c | 6 +- t/t3204-branch-locks.sh | 40 ++++ 10 files changed, 403 insertions(+), 165 deletions(-) create mode 100755 t/t3204-branch-locks.sh -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
