On 08/29/2013 12:21 PM, Junio C Hamano wrote: > Brad King <brad.k...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
