Re: [PATCH/RFC 0/7] Multiple simultaneously locked ref updates
- From
Brad King <brad.king@kitware.com>
- Date
- Aug 29, 2013, 18:23 UTC
- Message-ID
- <521F91B9.5030801@kitware.com>
- In-Reply-To
- <xmqqd2ow5q1h.fsf@gitster.dls.corp.google.com>
On 08/29/2013 02:07 PM, Junio C Hamano wrote:
Show 20 quoted lines
> 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