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