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@xxxxxxxxx> 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@xxxxxxxxx> 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
