Re: [PATCH v3] Add an option not to use link(src, dest) && unlink(src) when that is unreliable

[Linus Torvalds <torvalds@linux-foundation.org>]

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@linux-foundation.org>

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