Hi, On Tue, 20 Jan 2009, Jeff King wrote: > On Wed, Jan 21, 2009 at 01:10:22AM +0100, Johannes Schindelin wrote: > > > > Hmm. I suppose that would work, since every test run is trying to create > > > the same state. > > > > Yep, that's what I meant with "no race". > > Right, but it is still possible to screw it up, if your creation process > does a delete-create. But it looks like you did it correctly in your > patch (try to create, and if you fail because it's there, assume it's > right). Actually, I test first if it is there, and only if it is not, try to create the symlink. Now, there is still a very minor chance for a race, namely if two processes happen to test the existence of the missing symlink at exactly the same time, and both do not find it, so both processes will try to create it. However, the symlink creation is not checked for success, so the processes will still both run just fine. There is a very subtle problem, though. If you screw with your configuration, replacing a link in t/valgrind/ by a script, my code will not try to undo it. However, I think that's really asking for trouble, and you can get out of the mess by "rm -r t/valgrind/git*". Another problem which is potentially much more troublesome is this: when there was a script by a certain name, my code would symlink it to $GIT_DIR/$BASENAME (actually a relative path, but you get the idea). If that script is turned into a builtin -- this list has certainly known a certain person to push for that kind of conversion :-) -- that fact is not picked up. But I think I have an easy solution for that. > > In any case, I already found a bug in the nth_last series, thanks to > > your work, which I'll send in a minute. > > Yay! It's nice when infrastructure work like this actually pays off. Yep! Thanks! > Thanks for picking up this topic...I can drop the size of my > ever-growing git todo list by one. :) Actually, don't remind me... of my TODO list. Ciao, Dscho -- 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