Re: Bug: git pull output and case sensitivity.

From: Torsten Bögershausen <tboegi@web.de>
Date: Mar 20, 2023, 19:12 UTC
Message-ID: <20230320191210.jzzq5c2ssxcltvoc@tb-raspi4>
In-Reply-To: <_XGWc87b9HPBCDZ95pSmwNOFcZO21Y6bVyNnhhNuowPcM2Fhs5HmCynAqq2nME257bMhQ4w7Qta1dICTCHTlxbQ2NHN_iPYO0NkBYmS9vTI=@protonmail.com>

On Mon, Mar 20, 2023 at 06:01:30PM +0000, dooagain wrote:

> I'm not sure if this is helpful, but I documented a simple way to recreate the issue I am seeing in the README in the https://github.com/spencerdcarlson/test-casing repository.

It is helpful, thanks. In general, we prefer to have all informartion in emails ;-) Anyway.

To reply on Peff's comment:

>So I think this is just a known gotcha, and the path forward is probably
>a new ref storage format that doesn't rely on storing names directly in
>the filesystem (reftable, or some system based on packed-ref slices).

Yes, it is. The thing is, that Git at the moment is unable to handle to branches like Foo and foo on case-insensitive file systems. Because branch names are stored as files, and that doesn't typially work well under Windows or MacOs.

As a workaround, git pack-refs can be used.

side-note 1: a better backend for refs may make it's way into Git in the long term.

side-note 2: I always recommend to stick to a naming convention when working in a cross-platform project. You can keep filenames only lowercase. That is debatable, some people prefer camel-case rather then snake-case. So go for either way. But the same restriction/recommendation is valid for branch names as well, stick to one convention and avoid possible collisions under Mac or Windows.

Or run `git pack-refs`, but be aware the the performance may suffer, if you use zillions of refs.

HTH /Torsten

Show 38 quoted lines

>
> ------- Original Message -------
> On Monday, March 20th, 2023 at 11:16 AM, Jeff King <peff@peff.net> wrote:
>
>
> > On Sun, Mar 19, 2023 at 07:22:40AM +0100, Torsten Bögershausen wrote:
> >
> > > On Sat, Mar 18, 2023 at 07:21:10PM +0000, dooagain wrote:
> > >
> > > > Thank you for filling out a Git bug report!
> > > > Please answer the following questions to help us understand your issue.
> > > >
> > > > What did you do before the bug happened? (Steps to reproduce your issue)
> > > >
> > > > I configured my git repository to ignore case by executing `git config core.ignorecase true` then I executed `git pull` multiple times.
> > >
> > > What do you mean by "I configured my git repository" ?
> > > The answer is already there, so let's re-rephrase it:
> > > Are you working on a case-insensitive file system ?
> > >
> > > What happens if you create a test directory, like this:
> > > mkdir test-case
> > > cd test-case
> > > git init
> > > git config --get core.ignorecase
> >
> >
> > I think this is kind of a red herring, isn't it? The bug report is about
> > refs, and I don't think those really respect core.ignorecase either way,
> > and inconsistencies are known to happen on case-insensitive filesystems
> > (because the refs are sometimes case-sensitive and sometimes not
> > depending on whether they are packed or loose in the filesystem).
> >
> > So I think this is just a known gotcha, and the path forward is probably
> > a new ref storage format that doesn't rely on storing names directly in
> > the filesystem (reftable, or some system based on packed-ref slices).
> >
> > -Peff