On Thu, Dec 13, 2018 at 1:16 PM Mike Rappazzo <rappazzo@xxxxxxxxx> wrote: > > On Thu, Dec 13, 2018 at 3:48 PM Stefan Beller <sbeller@xxxxxxxxxx> wrote: > > > > > > 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 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. Thanks, Jake > > > > Maybe in worktree code we have a spillover between path > > resolution and ref namespace?
