Re: concurrent fetches to update same mirror

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