On Sat, Apr 12, 2014 at 11:19 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Duy Nguyen <pclouds@xxxxxxxxx> writes: > >> On Sat, Apr 12, 2014 at 3:43 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> Having said that, nobody sane would be running two simultaneous >>> operations that are clearly write-oriented competing with each other >>> against the same index file. >> >> When it comes to racing, sanity does not matter much. People could >> just do it without thinking what exactly is happening behind the >> scene. > > Well, "a race is a race is a race" would also be my knee-jerk > reaction when anybody utters the word "race", but you need to > realize that we are not talking about races like object creation > while "gc --auto" running in the background or two pushes trying to > update the same ref to different values, which are meaningful use > cases. > > What is the race under discussion about? It is about the index, > which corresponds one-to-one to the working tree, so in order for > the "race" to matter, you need to be racing against another process > that is not cooperating with you (e.g. a continuous and uncontrolled > "git add" updating the index while you are doing a real work), > mucking with the index in the same working tree. How could such a > workflow any useful in the real life? > > In the spectrum between useful and insane, there is a point where we > should just tell the insane: don't do it then. The thing is people do not usually have that level of knowledge of how git works. They could write a cron job to do something in some repos, not aware at all about these non-cooperations. Telling people not to automatically touch a git directory at all is a bit extreme. I think this patch is about guarding the user from shooting themselves. Either a command works correctly, not not work at all. A process' dying is a way of telling people "this is insane" without having to draw a line between dos and dont's in documents. Serializing write access to make both competing processes is nice, but that's a separate step that may or may not be worth pursuing. And I'm towards not worth pursuing. As you metioned in the next mail, serializing helps two competing processes, but not two command sequences. -- Duy -- 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