On Mon, 27 Apr 2009, Johannes Schindelin wrote: > > So, force the use of rename() instead of the link() && unlink() > incantation on Windows, and for good measure, add a > core.unreliableHardlinks option to optionally force it on other > platforms, too. Ok, so: Acked-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> but I do think it could be improved. See below.. > Junio, do you want me to remove the config variable? I'd keep it. But I'd suggest that the naming is odd. Why talk about "unreliable hardlinks", when that's just a particular symptom. Why not just talk about whether hardlinks should be used or not? And to avoid double negative, make it [core] usehardlinks = true/false and then default it to 'true' for Unix. The thing is, maybe people would prefer to use 'rename' over the link/unlink games even on some unixes, and not because of 'reliability' issues, but because they may have some filesystems that don't do hardlinks, and they'd just rather speed things up by avoiding the 'link()' system call that will just error out. So naming matters. Calling it 'unreliablehardlinks' in that case would be odd. They're not unreliable - you just don't want to try to use them. I also do wonder if we could/should make this one of those options that get set automatically at 'git init' time, rather than silently hardcoded as a compile option. I thought hardlinks at least sometimes worked fine on Windows too, don't they? I do detest _hidden_ default values for config options, unless those hidden defaults are "obviously always correct" as a default. This one smells a bit uncertain, and as a result I think it's ok to default to not using hardlinks, but doing it with .gitconfig would be nicer. Hmm? Linus -- 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