Re: Race condition on `git checkout -c`

From: Chris Torek <chris.torek@gmail.com>
Date: Jan 19, 2023, 22:55 UTC
Message-ID: <CAPx1GvcBDcZ1K_YJKm3+fUBNYQWKE2FBz-qS6JrV2TJCTc5k1w@mail.gmail.com>
In-Reply-To: <CAEcbrFdE6X6=ppBWmFZrm0Z2RqGqFatjNHdZbGb_RMteCk6P6g@mail.gmail.com>

(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