On 08/29/2013 02:07 PM, Junio C Hamano wrote: > 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. > >> - this process already has the lock because it was asked to >> update the same file multiple times simultaneously, or > > The second case is like left hand not knowing what right hand is > doing, no? It should not happen if we code it right. Yes. All of the above is what I originally intended when asking the question in the cover letter. Using string_list and its util field may be useful. However, see also my response at $gmane/233260 about how it may fold into sorting. Thanks for the reviews! -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