mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Torsten Bögershausen" <>
To: Mark Amery <>
Cc: Junio C Hamano <>,
Subject: Re: Bug: Changing folder case with `git mv` crashes on case-insensitive file system
Date: Thu, 6 May 2021 16:53:15 +0200	[thread overview]
Message-ID: <20210506145315.rrqcndm7esequ4ok@tb-raspi4> (raw)
In-Reply-To: <>

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.


  parent reply	other threads:[~2021-05-06 14:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-03 17:25 Bug: Changing folder case with `git mv` crashes on case-insensitive file system Mark Amery
2021-05-03 22:58 ` brian m. carlson
2021-05-04  3:46   ` Junio C Hamano
2021-05-04 11:20     ` brian m. carlson
2021-05-05 13:51       ` Johannes Schindelin
2021-05-06  0:38         ` Junio C Hamano
2021-05-04 15:19 ` Torsten Bögershausen
2021-05-05  0:23   ` Junio C Hamano
2021-05-05  2:12     ` brian m. carlson
2021-05-06  4:34     ` Torsten Bögershausen
2021-05-06  9:12       ` Mark Amery
2021-05-06 13:11         ` Bagas Sanjaya
2021-05-06 14:53         ` Torsten Bögershausen [this message]
2021-05-06 21:03         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210506145315.rrqcndm7esequ4ok@tb-raspi4 \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).