On 2021-05-04 at 03:46:12, Junio C Hamano wrote: > "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". Yes, although that won't work on Windows, which I don't believe has the concept of inodes and almost certainly has the same problem. CCing Dscho in case he has some ideas on how we can make this more resilient there. In any event, I'm not planning on writing a patch for this since I have no way to test it, but I'm sure someone who uses macOS could probably write one reasonably easily. -- brian m. carlson (he/him or they/them) Houston, Texas, US
Attachment:
signature.asc
Description: PGP signature
