Re: concurrent fetches to update same mirror

[Marc Branchaud <marcnarc@xiplink.com>]

On 11-01-06 06:45 PM, Jeff King wrote:
> On Wed, Jan 05, 2011 at 03:29:47PM -0800, Junio C Hamano wrote:
> 
>> Jeff King <peff@peff.net> writes:
>>
>>> Interestingly, in the case of ref _creation_, not update, like this:
>>>
>>>   mkdir repo && cd repo && git init
>>>   git remote add origin some-remote-repo-that-takes-a-few-seconds
>>>   xterm -e 'git fetch -v; read' & xterm -e 'git fetch -v; read'
>>>
>>> then both will happily update, the second one overwriting the results of
>>> the first. It seems in the case of locking a ref which previously didn't
>>> exist, we don't enforce that it still doesn't exist.
>>
>> We probably should, especially when there is no --force or +prefix is
>> involved.
> 
> Hmph. So I created the test below to try to exercise this, expecting to
> see at least one failure: according to the above example, we aren't
> actually checking "null sha1 means ref must not exist", so we should get
> an erroneous success for that case. And there is the added complication
> that the null sha1 may also mean "don't care what the old one was". So
> even if I changed the code, we would get erroneous failures the other
> way.
> 
> But much to my surprise, it actually passes with stock git. Which means
> I need to dig a little further to see exactly what is going on.

I should point out that the repository where I saw this issue is running git
1.7.1.

		M.