On Sat, Jun 29, 2024 at 10:39:29AM -0400, Julia Evans wrote:

When I run `git rev-parse head` inside a worktree on a case insensitive filesystem,
the result is different from `git rev-parse HEAD`.

This is a known issue in general. It can get even more confusing when
you pack refs, since we do case-sensitive matches within the packed-refs
file, and then the filesystem gives us case-insensitive matching for
loose refs.

I don't know of a good short-term solution, but the long-term one is for
us to eventually move to ref storage that doesn't rely on the filesystem
(like the recent reftables work).

With the current tip of 'master', you can do:

  git init --ref-format=reftable

I think initial support there shipped in v2.45.0, and I think things
should mostly work. But I won't be too surprised if you find a corner
case or rough edge somewhere. Bug reports welcome. ;)

Steps to reproduce, on a case insensitive filesystem:

$ git init
$ git commit --allow-empty -m'test'
$ git worktree add /tmp/myworktree
$ cd /tmp/myworktree
$ git commit --allow-empty -m'test'
$ git rev-parse head
adf59ca8da0ee5c4eb455f87efecc6c79eaf030f
$ git rev-parse hEAd
adf59ca8da0ee5c4eb455f87efecc6c79eaf030f
$ git rev-parse HEAD
fbb28196d08d74aa61f65e5cee3cb11cc24c338a

I admit this is an unexpected case, as I'd expect both on-disk files to
be spelled "HEAD". I didn't dig into the details, though, so it's
possible there's something we could be doing differently or better. But
I do think it's mostly the tip of the iceberg for case-insensitivity
issues with refs.

-Peff