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

"brian m. carlson" [off-list ref] writes:

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.
...
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.

I agree we'd probably need to resort to macOS specific hack (like we
have NFS or Coda specific hacks), but it may not be too bad.

After seeing EINVAL, we can lstat src 'foo' and dst 'FOO', and
realize that both are directories and have the same st_dev/st_ino,
which should be fairly straightforward, no?

For that, we do not exactly have to depend on any part of macOS-ism;
we do depend on the traditional "within the same device, inum is a
good way to tell if two filesystem entities are the same".

The (mis)design of "git mv a b c d ... DST" that turns the request
into "mv a DST/a && mv b DST/b && ..." too early may make the
fallback behaviour a bit cumbersome to implement (mainly, we need to
strip out the '/foo' part out of the failing dst FOO/foo to get the
real destination directory 'FOO' the user gave us, before checking
with that lstat dance), but since it is an error codepath, we can be
as inefficient as we like, as long as we are correct ;-)