Re: [PATCH 1/1] worktree refs: fix case sensitivity for 'head'

On Fri, Dec 14, 2018 at 7:50 AM Jacob Keller [off-list ref] wrote:

On Thu, Dec 13, 2018 at 1:16 PM Mike Rappazzo [off-list ref] wrote:

quoted

On Thu, Dec 13, 2018 at 3:48 PM Stefan Beller [off-list ref] wrote:

quoted

quoted

quoted

The current situation is definitely a problem.  If I am in a worktree,
using "head" should be the same as "HEAD".

By any chance, is your file system case insensitive?
That is usually the source of confusion for these discussions.

This behavior is the same for MacOS (High Sierra) and Windows 7.  I
assume other derivatives of those act the same.

On CentOS "head" is an ambiguous ref.  If Windows and Mac resulted in
an ambiguous ref, that would also be OK, but as it is now, they return
the result of "HEAD" on the primary worktree.

Because refs are *not* case sensitive, and we know that "HEAD" should
be per-worktree, it gets checked in the per-worktree refs section. But
lowercase head is known to not be a per-worktree ref, so we then ask
the main worktree about head. Since you happen to be on a case
insensitive file system, it then finds refs/HEAD in the main refs
worktree, and returns that.

I don't understand why the CentOS shows it as ambiguous, unless you
actually happen to have a ref named head. (possibly a branch?)

I think it's just our default answer when we can't decide

$ git rev-parse head
head
fatal: ambiguous argument 'head': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
$ git rev-parse head --
fatal: bad revision 'head'

I suspect we could improve things by attempting to figure out if our
file system is case insensitive and warn users. However, I recall
patches which tried this, and no suitable method was found. Partly
because it's not just "case" that is the only problem. There might be
things like unicode characters which don't get properly encoded, etc.

The best solution would be to get a non-filesystem backed ref storage
working that could be used in place of the filesystem.

Even with a new ref storage, I'm pretty sure pseudo refs like HEAD,
FETCH_HEAD... will forever be backed by filesystem. HEAD for example
is part of the repository signature and must exist as a file. We could
also lookup pseudo refs with readdir() instead of lstat(). On
case-preserving-and-insensitive filesystems, we can reject "head" this
way. But that comes with a high cost.
-- 
Duy