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

[Junio C Hamano <gitster@pobox.com>]

Brad King <brad.king@kitware.com> writes:

> 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.

I didn't mean to force the caller of new "update-ref --stdin"; the
new code you wrote for it is what feeds the input to update_refs()
function, and that is one place you can make sure you do not lock
yourself out.

Besides, if you get two updates to the same ref from --stdin, you
would need to verify these are identical (i.e. updating to the same
new object name from the same old object name; otherwise the requests
are conflicting and do not make sense), so the code to collect the
requests from stdin needs to match potential duplicates anyway.

One clean way to do so may be to put an update request (old and new
sha1) in a structure, and use a string_list to hold list of refs,
with the util field pointing at the update request data.

> 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.

The second case is like left hand not knowing what right hand is
doing, no?  It should not happen if we code it right.

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