Re: Confusing treatment of "head" in worktree on case-insensitive FS
- From
- Phillip Wood <phillip.wood123@gmail.com>
- Date
- Jul 1, 2024, 13:17 UTC
- Message-ID
- <bfa964a5-c366-47c7-a325-44fa4687432a@gmail.com>
- In-Reply-To
- <20240701033145.GB610406@coredump.intra.peff.net>
On 01/07/2024 04:31, Jeff King wrote:
Show 18 quoted lines
> On Sat, Jun 29, 2024 at 10:39:29AM -0400, Julia Evans wrote: >> $ 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.
I think what's happening is that the checks in is_current_worktree_ref() are case sensitive so "head" is not treated as local to the current worktree and ends up being resolved in the main worktree. I guess we could make those checks case-insensitive but as you say it'd only be dealing the tip of the iceberg.
On a related note do MacOs and Windows do any unicode normalization when looking up filenames? If so then that's probably another can of worms for filesystem based refs.
Best Wishes
Phillip