delta/git.git/refs.c, branch fc/mergetools-vimdiff3

Merge branch 'mh/safe-create-leading-directories'

2014-01-27T18:45:33+00:00

Code clean-up and protection against concurrent write access to the
ref namespace.

* mh/safe-create-leading-directories:
  rename_tmp_log(): on SCLD_VANISHED, retry
  rename_tmp_log(): limit the number of remote_empty_directories() attempts
  rename_tmp_log(): handle a possible mkdir/rmdir race
  rename_ref(): extract function rename_tmp_log()
  remove_dir_recurse(): handle disappearing files and directories
  remove_dir_recurse(): tighten condition for removing unreadable dir
  lock_ref_sha1_basic(): if locking fails with ENOENT, retry
  lock_ref_sha1_basic(): on SCLD_VANISHED, retry
  safe_create_leading_directories(): add new error value SCLD_VANISHED
  cmd_init_db(): when creating directories, handle errors conservatively
  safe_create_leading_directories(): introduce enum for return values
  safe_create_leading_directories(): always restore slash at end of loop
  safe_create_leading_directories(): split on first of multiple slashes
  safe_create_leading_directories(): rename local variable
  safe_create_leading_directories(): add explicit "slash" pointer
  safe_create_leading_directories(): reduce scope of local variable
  safe_create_leading_directories(): fix format of "if" chaining

Merge branch 'mh/retire-ref-fetch-rules'

2014-01-27T18:44:07+00:00

Code simplification.

* mh/retire-ref-fetch-rules:
  refname_match(): always use the rules in ref_rev_parse_rules

rename_tmp_log(): on SCLD_VANISHED, retry

2014-01-21T21:47:28+00:00

If safe_create_leading_directories() fails because a file along the
path unexpectedly vanished, try again from the beginning.  Try at most
4 times.

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

rename_tmp_log(): limit the number of remote_empty_directories() attempts

2014-01-21T21:47:24+00:00

This doesn't seem to be a likely error, but we've got the counter
anyway, so we might as well use it for an added bit of safety.

Please note that the first call to rename() is optimistic, and it is
normal for it to fail if there is a directory in the way.  So bump the
total number of allowed attempts to 4, to be sure that we can still
have at least 3 retries in the case of a race.

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

rename_tmp_log(): handle a possible mkdir/rmdir race

2014-01-21T21:47:13+00:00

If a directory vanishes while renaming the temporary reflog file,
retry (up to 3 times).  This could happen if another process deletes
the directory created by safe_create_leading_directories() just before
we rename the file into the directory.

As far as I can tell, this race could not occur internal to git.  The
only time that a directory under $GIT_DIR/logs is deleted is if room
has to be made for a log file for a reference with the same name;
for example, in the following sequence:

    git branch foo/bar    # Creates file .git/logs/refs/heads/foo/bar
    git branch -d foo/bar # Deletes file but leaves .git/logs/refs/heads/foo/
    git branch foo        # Deletes .git/logs/refs/heads/foo/

But the only reason the last command deletes the directory is because
it wants to create a file with the same name.  So if another process
(e.g.,

    git branch foo/baz

) wants to create that directory, one of the two is doomed to failure
anyway because of a D/F conflict.

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

rename_ref(): extract function rename_tmp_log()

2014-01-21T21:46:59+00:00

It's about to become a bit more complex.

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

lock_ref_sha1_basic(): if locking fails with ENOENT, retry

2014-01-21T21:46:30+00:00

If hold_lock_file_for_update() fails with errno==ENOENT, it might be
because somebody else (for example, a pack-refs process) has just
deleted one of the lockfile's ancestor directories.  So if this
condition is detected, try again (up to 3 times).

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

lock_ref_sha1_basic(): on SCLD_VANISHED, retry

2014-01-21T21:46:07+00:00

If safe_create_leading_directories() fails because a file along the
path unexpectedly vanished, try again (up to 3 times).

This can occur if another process is deleting directories at the same
time as we are trying to make them.  For example, "git pack-refs
--all" tries to delete the loose refs and any empty directories that
are left behind.  If a pack-refs process is running, then it might
delete a directory that we need to put a new loose reference in.

If safe_create_leading_directories() thinks this might have happened,
then take its advice and try again (maximum three attempts).

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

refname_match(): always use the rules in ref_rev_parse_rules

2014-01-14T21:58:06+00:00

We used to use two separate rules for the normal ref resolution
dwimming and dwimming done to decide which remote ref to grab.  The
third parameter to refname_match() selected which rules to use.

When these two rules were harmonized in

    2011-11-04 dd621df9cd refs DWIMmery: use the same rule for both "git fetch" and others

, ref_fetch_rules was #defined to avoid potential breakages for
in-flight topics.

It is now safe to remove the backwards-compatibility code, so remove
refname_match()'s third parameter, make ref_rev_parse_rules private to
refs.c, and remove ref_fetch_rules entirely.

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

Merge branch 'mh/shorten-unambigous-ref'

2014-01-13T19:34:08+00:00

* mh/shorten-unambigous-ref:
  shorten_unambiguous_ref(): tighten up pointer arithmetic
  gen_scanf_fmt(): delete function and use snprintf() instead
  shorten_unambiguous_ref(): introduce a new local variable