Re: Bug: lowercase "head" resolves to wrong commit in linked worktrees on case-insensitive filesystems

From: D. Ben Knoble <ben.knoble@gmail.com>
Date: May 13, 2026, 15:42 UTC
Message-ID: <CALnO6CAZ+Z_ZzkqXHu45A3cwZTZD4=MEz-vx0PEoD05bJ=0bzw@mail.gmail.com>
In-Reply-To: <95BE8E60-1684-4E0A-9E46-E61E81D06CE1@alexandersandstrom.se>

On Wed, May 13, 2026 at 4:27 AM Alexander Sandström <mail@alexandersandstrom.se> wrote:

Show 18 quoted lines

>
> Hello everyone,
>
> I ran into a bug that took me a while to figure out.
>
> I'm sadly not a good enough C programmer to submit a proper patch,
> but perhaps this bug report will at least be indexed by search engines
> and help others that might have this issue to understand the cause.
>
> My guess is that it will happen much more frequently now that
> worktrees are more popular.
>
> **Report**
>
> On case-insensitive filesystems (macOS APFS/HFS+), `git rev-parse head`
> (lowercase) in a linked worktree resolves to the main worktree's HEAD
> rather than the current worktree's HEAD. This causes commands like
> `git reset --soft head~1` to silently operate on the wrong commit.

See also https://lore.kernel.org/git/20240701033145.GB610406@coredump.intra.peff.net/ and https://lore.kernel.org/git/8BABB6F0-517F-4AA0-9FF9-92AF8C33CD0E@strongestfamilies.com/

In short, it's a known issue (that I don't think we're going to solve in the ref store where refs are just named files). Using reftables ought to make the papercuts go away.

-- 
D. Ben Knoble