Re: bug: HEAD vs. head on case-insensitive filesystems
> I was going to point you to the recent thread in > > http://public-inbox.org/git/87ziclb2pa@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".
bug: HEAD vs. head on case-insensitive filesystems
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: Should "head" also work for "HEAD" on case-insensitive FS?
On Tue, Jul 04, 2017 at 10:19:09AM +0300, Konstantin Khomoutov wrote: > On Tue, Jul 04, 2017 at 12:00:49AM +0200, Ævar Arnfjörð Bjarmason wrote: > > > I don't have a OSX box, but was helping a co-worker over Jabber the > > other day, and he pasted something like: > > > > $ git merge-base github/master head > > > > Which didn't work for me, and I thought he had a local "head" branch > > until realizing that of course we were just resolving HEAD on the FS. > > > > Has this come up before? I think it makes sense to warn/error about > > these magic /HEAD/ revisions if they're not upper-case. > > > > This is likely unintentional and purely some emergent effect of how it's > > implemented, and leads to unportable git invocations. > > JFTR this is one common case of confusion on Windows as well. > To the point that I saw people purposedly using "head" on StackOverflow > questions. That is, they appear to think (for some reason) that > branches in Git have case-insensitive names and prefer to spell "head" > since it (supposedly) easier to type. The use of "head" also appears to be leading to some strange behavior when resolving refs on Windows. See the following issue in the git-for-windows project: https://github.com/git-for-windows/git/issues/1225 In summary, it seems that head and HEAD can resolve to different revisions when in a worktree.
