Re: Git apply fails on case-only rename on case-insensitive filesystem

From: Tao Klerks <tao@klerks.biz>
Date: Jun 9, 2022, 04:57 UTC
Message-ID: <CAPMMpoi=4Ke=Zq1ZRR7Y4nbO_1jTBe4to7p9qKtuY-UoFxaXRw@mail.gmail.com>
In-Reply-To: <YqEiPf/JR/MEc3C/@camp.crustytoothpaste.net>

On Thu, Jun 9, 2022 at 12:27 AM brian m. carlson <sandals@crustytoothpaste.net> wrote:

>
> Git wants to create the new
> file before deleting the old one, but it already exists.
>

Ah, thanks for that observation, I didn't consider that git might generally want to do renames in a "safe" order.

Show 5 quoted lines

> 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 have not yet tried to find out whether this "sameness determination" is possible in windows, but I have one more interesting observation: I just realized that "git checkout" probably wants to do the same thing in the same safe order, and indeed, when I do "git config core.ignorecase false" the "checkout" command fails with a very similar error:

error: The following untracked working tree files would be overwritten
by checkout:
        file1
Please move or remove them before you switch branches.
Aborting

(in fact, even "git mv" fails with a similar error)

This suggests that there is a strategy based on the "core.ignorecase" config, which might not hinge on determining the "sameness" of differing-only-in-case files, which is applied in other places and simply wasn't considered in "git apply" yet.

> I don't think anyone's working on such a thing at
> the moment, though.

Thanks, I'll try to look a little deeper at some point.