On 11-01-07 09:50 AM, Marc Branchaud wrote: > 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@xxxxxxxx> 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. Oops -- sorry! I'm in the wrong concurrency thread... M. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html