Re: [PATCH v2] Allow git mv FileA fILEa on case ignore file systems

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 11, 2011, 16:55 UTC
Message-ID: <7vd3ksybfr.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4DA144A5.2080103@web.de>

Torsten Bögershausen <tboegi@web.de> writes:

Show 14 quoted lines

>>When two different _names_ "A" and "a" refer to a single file, the only
>>thing that should happen for "git mv A a" is for the cache entry for "A"
>>to be moved to cache entry for "a", and no rename("A", "a") should be run,
>>but I don't see any such change in the code. It may happen to work (or be
>>a no-op) on Windows, but because builtin/mv.c is supposed to be generic
>>(and that is the reason you introduced the is_same_file() abstraction in
>>the first place), I'd still see this as a breakage.
>>
> Why shouldn't the rename() be done?
> "git mv A B" changes both the indes and the file system.
> Isn't it natural to have file name  "a" both in the index and in the 
> file system after "git mv A a"?
> Note: Windows and MAC OS X allow "mv A a" from command line, 
> while Linux on VFAT gives an error "'A' and 'a' are the same file".

Yeah, I forgot about the primary thing we are trying to do in this discussion. Sorry about that. My thinking stopped at 'if we rename "A" to "a in the index, that is sufficient. We already know that we can still open("A") because the filesystem is case insensitive.'

In fact, we want both the index entry "A" renamed to "a" _and_ also we want to see next "/bin/ls" to show "a", not "A". For the latter, we do want to run rename(2) on them.

There was another thing that made me worry about running rename(2) on two equivalent filenames. You said on Linux VFAT "mv A a" fails. Does the underlying rename(2) fail when you do this?

	status = rename("A", "a");

If old and new resolve to the same existing directory entry or different directory entries for the same existing file, POSIX says that rename(old, new) should succeed and perform no other action, so the above should succeed on correctly implemented case insensitive filesystems.

But we know not all FS implementations are perfect. If this can result in an unnecessary failure, it would be far better if we are careful to avoid running rename("A", "a") and just rename the index entry to make sure "git mv A a" succeeds, than trying to fulfil the "we want to see next '/bin/ls' to show 'a' not 'A'" wish and make the whole "git mv A a" fail.

But of course we can always blame the breakage on filesystems. I am leaning to prefer running rename("A", "a") unconditionally.

Thanks.