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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 2929 bytes --]

On 2021-05-03 at 17:25:43, Mark Amery wrote:
> Attempting to change the case of a folder's name using a command like
> `git mv foo FOO` crashes on case-insensitive file systems, like the
> default APFS used on Apple Macs.
> 
> Here are simple steps to repro this:
> 
>     $ mkdir testrepo && cd testrepo && git init
>     Initialized empty Git repository in /Users/markamery/testrepo/.git/
>     $ mkdir foo && touch foo/bar && git add foo && git commit -m bla
>     [master (root-commit) a7e9f5f] bla
>     1 file changed, 0 insertions(+), 0 deletions(-)
>     create mode 100644 foo/bar
>     $ git mv foo FOO
>     fatal: renaming 'foo' failed: Invalid argument
>     $ echo $?
>     128
>     $ git status
>     On branch master
>     nothing to commit, working tree clean
> 
> If I create a case-sensitive APFS volume using Disk Utility and try
> the commands above on that volume, `git mv foo FOO` works correctly:
> it emits no output, exits with a 0 status code, and stages a change
> renaming `foo/bar` to `FOO/bar`. However, on my main case-insensitive
> volume, `git mv` behaves as shown above: it exits with code 128,
> prints an "Invalid argument" error message, and does not stage any
> changes.

Yeah, this is because your operating system returns EINVAL in this case.
POSIX specifies EINVAL when you're trying to make a directory a
subdirectory of itself.  Which, I mean, I guess is a valid
interpretation here, but it of course makes renaming the path needlessly
difficult.

> The command still fails in the same way if you use `git mv --force`
> instead of just `git mv`.
> 
> Note that previously, `git mv` could not change the case of *file*
> names on case-insensitive file systems, until that was fixed in commit
> https://github.com/git/git/commit/baa37bff9a845471754d3f47957d58a6ccc30058.
> I'm guessing there's a different code path that needs fixing for
> changing the case of *folders*.

My guess is this is because when the argument is a directory, the mode
is set to WORKING_DIRECTORY, and then we check that the mode isn't INDEX
and so rename(2) gets called.  However, I believe there is a -k option
which should make this work, since we ignore the errors.

I suspect part of the problem here is two fold: on macOS we can't
distinguish an attempt to rename the path due to it folding or
canonicalizing to the same thing from a real attempt to move an actual
directory into itself.  The latter would be a problem we'd want to
report, and the former is not.  Unfortunately, detecting this is
difficult because that means we'd have to implement the macOS
canonicalization algorithm in Git and we don't want to do that.

Maybe someone who frequently uses a macOS system that uses a
case-sensitive file system can chime in here, but for now, I think -k
should do what you want.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]