On 01/07/2024 04:31, Jeff King wrote:
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
