Re: [PATCH/RFC 0/7] Multiple simultaneously locked ref updates

[Brad King <brad.king@kitware.com>]

On 08/29/2013 12:21 PM, Junio C Hamano wrote:
> Brad King <brad.king@kitware.com> writes:
>> needs to reject duplicate ref names from the stdin lines before
>> trying to lock the ref twice to avoid this message.
> 
> How about trying not to feed duplicates?

Sure, perhaps it is simplest to push the responsibility on the user
to avoid duplicates.  However, the error message will need to be
re-worded to distinguish this case from a stale lock or competing
process since both locks may come from the same update-ref process.

Without checking the input for duplicates ourselves we cannot
distinguish these cases to provide a more informative error message.
However, such a check would add runtime overhead even for valid input.
If we prefer to avoid input validation then here is proposed new
wording for the lock failure message:

--------------------------------------------------------------------
fatal: Unable to create '....lock': File exists.

The lock file may exist because:
- another running git process already has the lock, or
- this process already has the lock because it was asked to
  update the same file multiple times simultaneously, or
- a stale lock is left from a git process that crashed earlier.
In the last case, make sure no other git process is running and
remove the file manually to continue.
--------------------------------------------------------------------

IIUC the message cannot say anything about a 'ref' because it is
used for other file type lock failures too.

Comments?
-Brad