Re: Race condition on `git checkout -c`

From: Arthur Milchior <arthur.milchior@gmail.com>
Date: Jan 20, 2023, 09:01 UTC
Message-ID: <CAEcbrFdfZsRAxeMj+z_VBxHbtgBDKHC51rDz0duM3a0TFzqB-A@mail.gmail.com>
In-Reply-To: <CAPx1GvcBDcZ1K_YJKm3+fUBNYQWKE2FBz-qS6JrV2TJCTc5k1w@mail.gmail.com>

Thank you very much for the explanation. I’m ever so happy not to be working at the file system level nor on cross platform app. Alas, it’s a computer configured by work, so not only do I have no control over the disk configuration, but I’m not even allowed to plus external storage. So I guess I’ll just remain with the case almost-insensitive branch. Not like I expect this to occur again in the future.

Good luck with whatever next change git plans.

Regards, Arthur

On Thu, Jan 19, 2023 at 11:56 PM Chris Torek <chris.torek@gmail.com> wrote:

Show 55 quoted lines

>
> (Top note: you mean `git checkout -b` or `git switch -c`, not `git
> checkout -c`.)
>
> On Thu, Jan 19, 2023 at 1:24 PM Arthur Milchior
> <arthur.milchior@gmail.com> wrote:
> >
> > I expect either:
> > * to see an error message stating that `b` already exists
> > * to see `b` and `B` in the list of branch.
>
> [snip]
>
> > uname: Darwin 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:03:51
>
> Darwin (macOS) is your problem here.  The same problem
> occurs on Windows, but not on Linux, by default.
>
> Technically the problem is in the file system itself, combined with
> the ways (plural) that Git stores branch names.
>
> As far as Git itself is concerned, branch names are *always* case
> sensitive, so branches named `b` and `B` are different.  But Git
> stores branch names in two different formats, at the moment:
>
>  * Some are kept in a plain-text file `.git/packed-refs`.
>  * Some are stored as directory-and-file-names in `.git/refs/`.
>
> If the OS's file system is case sensitive, as most standard Linux
> file systems are, there's no problem with the latter. But if the OS's
> file system is case-INsensitive, as the default file systems on
> Windows and MacOS are, this becomes a problem: the attempt
> to create both `refs/heads/b` and a different file, `refs/head/B`,
> fails, with one of the two names "winning" and the other attempt
> to create a new name simply re-using the existing name.
>
> If you create a case-sensitive disk volume on your Mac, which
> can be a simple click-to-mount virtual drive within your regular
> case-insensitive file system, you can happily use Git without this
> complication. Note that the same complication applies to file
> names: Linux users can create two different, separate files
> named `README.TXT` and `ReadMe.txt` in a GIt project, and
> if you use the default case-insensitive macOS file system, you
> won't be able to check out both files.  Using your case sensitive
> volume will allow you to work with the Linux group.
>
> If and when a future version of Git starts using reftables instead
> of the file system to store branch and tag names, this particular
> issue will go away, but until then, I recommend keeping a case
> sensitive volume handy on your mac, and more generally,
> avoiding mixing upper and lower case branch and/or file names
> (at all, ever) whenever possible.  This avoids a lot of problems,
> though nothing can get you past the Windows `aux.h` problem. :-)
>
> Chris