Re: concurrent fetches to update same mirror

On 11-01-07 09:50 AM, Marc Branchaud wrote:

On 11-01-06 06:45 PM, Jeff King wrote:

quoted

On Wed, Jan 05, 2011 at 03:29:47PM -0800, Junio C Hamano wrote:

quoted

Jeff King [off-list ref] writes:

quoted

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.

Oops -- sorry!  I'm in the wrong concurrency thread...

		M.