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