bug: HEAD vs. head on case-insensitive filesystems

bug: HEAD vs. head on case-insensitive filesystems

[Kenneth Hsu]

I'm not sure what the general consensus is regarding the use of "head"
vs. "HEAD" on case insensitive filesystems, but it appears that some
confusing behavior (bug?) may have arisen.

To summarize, "HEAD" and "head" may resolve to different revisions when
in a worktree.  The following example was generated using git version
2.13.1 for Mac (HFS+):

$ git --version
git version 2.13.1
$ git init
Initialized empty Git repository in /Users/ken/Desktop/test/.git/

$ echo "Hello" > hello.txt
$ git add . && git commit -qm "Add hello."

$ echo "Bye" > bye.txt
$ git add . && git commit -qm "Add bye."

Note that at this point, both HEAD and head (correctly) resolve to the
same revision:

$ git rev-parse HEAD
4a71a947fb683698f80f543f9cd27acd066e2659

$ git rev-parse head
4a71a947fb683698f80f543f9cd27acd066e2659

However, if we create (and cd into) a worktree based on "master~", "HEAD" and
"head" resolve to _different_ revisions:

$ git worktree add -b feature/branch ../branch master~
Preparing ../branch (identifier branch)
HEAD is now at f752545 Add hello.
$ cd ../branch/

$ git rev-parse HEAD
f7525451640f6f5e8842cc00b6639c80558dd6c2

$ git rev-parse head
4a71a947fb683698f80f543f9cd27acd066e2659

$ git rev-parse master
4a71a947fb683698f80f543f9cd27acd066e2659

$ git rev-parse master~
f7525451640f6f5e8842cc00b6639c80558dd6c2

$ git rev-parse feature/branch
f7525451640f6f5e8842cc00b6639c80558dd6c2

Note that "HEAD" resolves to the same revision as "master~" and
"feature/branch" (which seems correct since that is what the worktree
was based on), while "head" resolves to the same revision as "master".

This appears to affect other case-insensitive filesystems (Windows) as
well.  See the following bug report:

https://github.com/git-for-windows/git/issues/1225

I'm not sure if the behavior is well-defined when using "head", but the
above example may illustrate a case where users should not assume that
they resolve to the same thing.

Thanks.

Re: bug: HEAD vs. head on case-insensitive filesystems

[Jeff King]

On Mon, Jul 10, 2017 at 08:32:36PM -0700, Kenneth Hsu wrote:

> I'm not sure what the general consensus is regarding the use of "head"
> vs. "HEAD" on case insensitive filesystems, but it appears that some
> confusing behavior (bug?) may have arisen.

Generally, the advice on "head" is "don't". It's an accident that
it works at all, and as you noticed, there are odd corner cases. There
are similar oddities when mixing and matching case for other refnames on
case-insensitive filesystems, too.

I was going to point you to the recent thread in

  http://public-inbox.org/git/87ziclb2pa.fsf@gmail.com/

but I see you already participated there. So if your mail here is
"here's a summary of how HEAD/head don't quite work", then OK, that
might be handy. But I think the ultimate resolution is not "let's make
them work", but "let's consistently enforce case-sensitivity in ref
names, regardless of the underlying filesystem".

-Peff

Re: bug: HEAD vs. head on case-insensitive filesystems

[Kenneth Hsu]

> I was going to point you to the recent thread in
> 
>   http://public-inbox.org/git/87ziclb2pa.fsf@gmail.com/
> 
> but I see you already participated there. So if your mail here is
> "here's a summary of how HEAD/head don't quite work", then OK, that
> might be handy. But I think the ultimate resolution is not "let's make
> them work", but "let's consistently enforce case-sensitivity in ref
> names, regardless of the underlying filesystem".

Thanks, that makes sense.  Perhaps it's best to just view my original
message as, "here's a new example of where 'head' doesn't work".