[PATCH 00/22] Lockfile refactoring and pre-activation

[Michael Haggerty <mhagger@alum.mit.edu>]

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