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