On 2022-06-08 at 13:07:05, Tao Klerks wrote: > Hi folks, > > I just found out that "git apply" has a faulty existence check on > case-insensitive filesystems (or, at least, windows?). > > Simplest repro I could come up with: > > git init renamefun > cd renamefun > echo "Test" > file1 > git add . > git commit -m "first commit" > git mv file1 File1 > git commit -m "second commit" > git checkout master~1 > git diff master~1..master | git apply > > -> error: > error: File1: already exists in working directory Your problem here is that the file does already exist. To Windows "file1" and "File1" are the same file. Git wants to create the new file before deleting the old one, but it already exists. > (on linux, the same sequence of commands completes correctly) > > I was able to work around this for my purposes by avoiding rename > detection on the diff, and only passing the "Add" (and "Modify") > operations through to the "apply", after having separately/manually > handled the deletions. > > Is this a known issue that someone might be working on, or worth > digging into / trying to fix? As I explained to someone else just today, the rules for case-folding on Windows differ based on the version of the tool that was used to format the file system and cannot be inspected without reading the raw file system. (This is also true of macOS.) Thus, we cannot know ahead of time whether two files differ only in case. The way we could determine this on Unix would be to stat both files and compare device and inode data when we get EEXIST, but I don't think our Windows stat emulation supports that. Having said that, for case-insensitive macOS, I think the rename detection could be fixed here using that technique. I don't think anyone's working on such a thing at the moment, though. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
