Re: Confusing treatment of "head" in worktree on case-insensitive FS

From: Jeff King <peff@peff.net>
Date: Jul 1, 2024, 03:31 UTC
Message-ID: <20240701033145.GB610406@coredump.intra.peff.net>
In-Reply-To: <A72DCB1B-8D81-4DD7-93AD-BF37E88E9D63@jvns.ca>

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. ;)

Show 13 quoted lines

> 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