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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux