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

[Junio C Hamano <gitster@pobox.com>]

Linus Torvalds <torvalds@linux-foundation.org> writes:

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

I am a bit worried about this name, too.  It may lead people to a
misunderstanding that we would do something magical when they do this with
the configuration set:

	wget http://some.where/huge-file.mpg 1.mpg
        ln 1.mpg 2.mpg
        git add 1.mpg 2.mpg
        rm -f 1.mpg 2.mpg
        git checkout-index -a
	ls -i ?.mpg

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

This part I agree with.

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

The coda hack comment in move_temp_to_file() shows what we can do to
autodetect (i.e. try cross directory hardlink), but I somehow thought that
we changed the code enough to ensure that we create the tmpfiles in the
same directory as their final destination?