Torsten BÃgershausen <tboegi@xxxxxx> writes:
>>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.
--
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