If you try to switch to a branch (e.g. `master`), but get the case wrong, e.g:
git switch MASTER
git checkout MASTER
git switch Master
git checkout Master
etc. then it autocorrects the case (bad idea but ok), but it also
enables the `--detach` flag! In other words
git switch Master
acts like
git switch -d master
Very unexpected!
Cheers,
Tim
[System Info]
git version:
git version 2.32.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Darwin 20.4.0 Darwin Kernel Version 20.4.0: Fri Mar 5 01:14:14
PST 2021; root:xnu-7195.101.1~3/RELEASE_X86_64 x86_64
compiler info: clang: 12.0.5 (clang-1205.0.22.9)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh
[Enabled Hooks]
If you try to switch to a branch (e.g. `master`), but get the case wrong, e.g:
git switch MASTER
git checkout MASTER
git switch Master
git checkout Master
etc. then it autocorrects the case (bad idea but ok), but it also
enables the `--detach` flag! In other words
git switch Master
acts like
git switch -d master
Very unexpected!
This behavior isn't intentionaly, but ultimately isn't with Git, but
with your running of Git on a filesystem that doesn't respect POSIX
semantics.
The default FS on OSX is case insensitive, we store the "master"
reference (unpacked) under that name on the FS, so this is emergent
behavior. Can you reproduce this after a:
git pack-refs --all
?
Even after that we'll have a .git/HEAD, and I know on OSX e.g. "git log
head...<branch>" unintentionally resolved to "HEAD" too at some point
(probably still).
There's various workarounds in git's code to deal with funny behavior on
OSX, but it's hard to catch them all as it means having to second-guess
standard library calls. I think you're best off creating a
case-sensitive partition on your computer and using git there if you
want to avoid these cases entirely.
[System Info]
git version:
git version 2.32.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Darwin 20.4.0 Darwin Kernel Version 20.4.0: Fri Mar 5 01:14:14
PST 2021; root:xnu-7195.101.1~3/RELEASE_X86_64 x86_64
compiler info: clang: 12.0.5 (clang-1205.0.22.9)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh
[Enabled Hooks]
Yeah that "fixes" things so you get `fatal: invalid reference: MASTER`.
I guess `git checkout` checks whether `MASTER` exists (yes, according
to MacOS), but git log checks whether the current branch (`MASTER`)
matches `master` (it doesn't).
Very unfortunate, but I guess it's not worth fixing.
Cheers,
Tim
On Sun, 20 Jun 2021 at 23:09, Ævar Arnfjörð Bjarmason [off-list ref] wrote:
On Sun, Jun 20 2021, Tim Hutt wrote:
quoted
If you try to switch to a branch (e.g. `master`), but get the case wrong, e.g:
git switch MASTER
git checkout MASTER
git switch Master
git checkout Master
etc. then it autocorrects the case (bad idea but ok), but it also
enables the `--detach` flag! In other words
git switch Master
acts like
git switch -d master
Very unexpected!
This behavior isn't intentionaly, but ultimately isn't with Git, but
with your running of Git on a filesystem that doesn't respect POSIX
semantics.
The default FS on OSX is case insensitive, we store the "master"
reference (unpacked) under that name on the FS, so this is emergent
behavior. Can you reproduce this after a:
git pack-refs --all
?
Even after that we'll have a .git/HEAD, and I know on OSX e.g. "git log
head...<branch>" unintentionally resolved to "HEAD" too at some point
(probably still).
There's various workarounds in git's code to deal with funny behavior on
OSX, but it's hard to catch them all as it means having to second-guess
standard library calls. I think you're best off creating a
case-sensitive partition on your computer and using git there if you
want to avoid these cases entirely.
quoted
[System Info]
git version:
git version 2.32.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Darwin 20.4.0 Darwin Kernel Version 20.4.0: Fri Mar 5 01:14:14
PST 2021; root:xnu-7195.101.1~3/RELEASE_X86_64 x86_64
compiler info: clang: 12.0.5 (clang-1205.0.22.9)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh
[Enabled Hooks]
From: brian m. carlson <hidden> Date: 2021-06-23 02:39:11
On 2021-06-21 at 17:20:28, Tim Hutt wrote:
Ah of course!
quoted
git pack-refs --all
Yeah that "fixes" things so you get `fatal: invalid reference: MASTER`.
I guess `git checkout` checks whether `MASTER` exists (yes, according
to MacOS), but git log checks whether the current branch (`MASTER`)
matches `master` (it doesn't).
Very unfortunate, but I guess it's not worth fixing.
I should point out that there is work underway to add a ref backend
called reftable that doesn't store things in the file system and hence
doesn't suffer from this problem. It's just a big project and it
involves touching a lot of code, so it's slow going, but when it's
completed, people who are using that won't have this problem ("MASTER"
will be rejected if the branch is "master").
You aren't the first person to report this problem in some variation (it
comes up quite frequently); we've known about it a long time, but fixing
it just isn't trivial. In the mean time, you may prefer to adopt a
naming convention for your project branches; for example, even though I
use Linux and don't have this problem, I always use lowercase, which
makes things easier for colleagues on other systems (and is also easier
to type).
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
On Wed, 23 Jun 2021 at 03:38, brian m. carlson
[off-list ref] wrote:
I should point out that there is work underway to add a ref backend
called reftable that doesn't store things in the file system and hence
doesn't suffer from this problem.
[...] In the mean time, you may prefer to adopt a naming convention
for your project branches; for example, even though I use Linux and
don't have this problem, I always use lowercase, which makes things
easier for colleagues on other systems (and is also easier to type).
The reported issue is one that doesn't have to do with the naming of the
branch itself, but git accepting it due to how the ref backend interacts
with the FS.
As noted I've run into e.g. people writing unportable "head.." code,
which we happily resolve to "HEAD"., ditto "master", "Master", "MASTER"
etc. on OSX.