Re: Bug: Changing folder case with `git mv` crashes on case-insensitive file system

["Torsten Bögershausen" <tboegi@web.de>]

On Thu, May 06, 2021 at 10:12:40AM +0100, Mark Amery wrote:
> So, I'm just a dumb Git user who doesn't even write C, so much of this
> discussion is over my head, but I have a few thoughts that may be
> helpful:
>
> • The mv utility on Mac is capable of doing `mv bär.txt bÄr.txt` just
> fine. Maybe `git mv` can learn something from whatever `mv` does?

Yes, Git can do the same.
The thing is, that Git avoids to overwrite of existing files.
Just to be nice.
In that sense, if the destination exists, Git refuses the mv,
unless you use git mv -f
Having said that,
git mv bär.txt bÄr.txt will not work (without the -f)

git mv bear.txt BEAR.txt does work,

>
> • On a case-insensitive file system, `git mv somedir sOMEdir` is a
> rename. But on a case-sensitive file system, it might NOT be a rename;
> it might be the case that `somedir` and `sOMEdir` both exist and that
> the command should put `somedir` inside `sOMEdir`. I mention this
> because I can imagine some naive attempts at fixing the original bug
> by doing a case-insensitive comparison of the two names ending up
> breaking this behaviour on case-sensitive file systems by wrongly
> treating such a command as a rename. It's probably worth having a test
> that this scenario gets handled cleanly on case-sensitive file
> systems? (I haven't checked whether Torsten's proposed diff falls into
> this trap or not.)

Tests are needed - I should have started with those.
But I didn't intend to send a patch (yet), just sharing
ideas and knowledge. Which may enable someone to write a patch.

>
> • Above, Torsten mentions that there are filesystem-specific rules
> about what names are equal to each other that Git can't easily handle,
> because they go beyond just ASCII case changes. In that case, maybe
> the right solution is to always defer the question to the filesystem
> rather than Git trying to figure out the answer "in its head"?

There are different trade-offs:
So far I am only aware of people asking for the
git mv bear.txt BEAR.txt rename.
Just because they are all SW developers ? I don't know.
And just because SW developers are developping Git,
the case-insensitive string compare is good enough,
it is working for them/us.
So things are as they are.

>
>   That is: first check the inode or file ID of the src and dst passed
> to `git mv`. If they are different and the second one is a folder,
> move src inside the existing folder. If either they are the same or
> the second one is not a folder, then do a rename.

Yes. In short: patches are welcome.
In long: inodes don't work on Windows (without a major effort)

>
>   It seems to me that this approach automatically handles stuff like
> `git mv bär.txt bÄr.txt` plus any other rules about names being equal
> (like two different sequences of code points that both express "à"),
> all without Git ever needing to explicitly check whether two names are
> case-insensitively equal. Am I missing something?

That could be a solution. There may are situations/configurations,
where inodes don't work:
What happens if a Windows server exports a file system to MacOs ?
To Linux ?
Do we have working inodes ?
What about other networking combinations ?
Our code should handle them well as well.

>
> Sorry if any of the above is dumb or if I'm reiterating things others
> have already said without realising it.

No problem. Actually I realized that we used top-posting here,
So I remove the reset to make it more readable.

[]