"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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 ;-)
