git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arthur Milchior <arthur.milchior@gmail.com>
To: Chris Torek <chris.torek@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Race condition on `git checkout -c`
Date: Fri, 20 Jan 2023 10:01:21 +0100	[thread overview]
Message-ID: <CAEcbrFdfZsRAxeMj+z_VBxHbtgBDKHC51rDz0duM3a0TFzqB-A@mail.gmail.com> (raw)
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:
>
> (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

      reply	other threads:[~2023-01-20  9:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-19 21:13 Race condition on `git checkout -c` Arthur Milchior
2023-01-19 22:55 ` Chris Torek
2023-01-20  9:01   ` Arthur Milchior [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEcbrFdfZsRAxeMj+z_VBxHbtgBDKHC51rDz0duM3a0TFzqB-A@mail.gmail.com \
    --to=arthur.milchior@gmail.com \
    --cc=chris.torek@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).