Re: [PATCH/RFC 0/7] Multiple simultaneously locked ref updates
- From
Brad King <brad.king@kitware.com>
- Date
- Aug 29, 2013, 17:09 UTC
- Message-ID
- <521F8033.6070302@kitware.com>
- In-Reply-To
- <xmqq7gf479jm.fsf@gitster.dls.corp.google.com>
On 08/29/2013 12:21 PM, Junio C Hamano wrote:
Show 5 quoted lines
> 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