Should "head" also work for "HEAD" on case-insensitive FS?

Should "head" also work for "HEAD" on case-insensitive FS?

[Ævar Arnfjörð Bjarmason]

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.

Re: Should "head" also work for "HEAD" on case-insensitive FS?

[Konstantin Khomoutov]

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.

I don't know what to do about it.
Ideally we'd just have a way to perform a final check on the file into
which a ref name was resolved to see its "real" name but I don't know
whether all popular filesystems are case preserving (HFS+ and NTFS are,
IIRC) and even if they are, whether the appropriate platform-specific
APIs exists to perform such a check.

Re: Should "head" also work for "HEAD" on case-insensitive FS?

[Ævar Arnfjörð Bjarmason]

On Tue, Jul 04 2017, Konstantin Khomoutov jotted:

> 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.
>
> I don't know what to do about it.
> Ideally we'd just have a way to perform a final check on the file into
> which a ref name was resolved to see its "real" name but I don't know
> whether all popular filesystems are case preserving (HFS+ and NTFS are,
> IIRC) and even if they are, whether the appropriate platform-specific
> APIs exists to perform such a check.

I think there's no easy way do this in the general case with the current
ref backend, because we rely on the FS to store the refs.

But I'm thinking of the more specific case where you specify
{HEAD,FETCH_HEAD,ORIG_HEAD,MERGE_HEAD,CHERRY_PICK_HEAD} as non-upper
case, and we resolve it from .git/$NAME.

So the detection would not be checking whether the file on-disk has the
same casing, but knowing that if we resolve anything from .git/$NAME
then the string provided on the command-line must be upper-case.

Although there is this:

    $ git rev-parse HEAD
    051ee1e7dd2c7b8bdc20f237eea3c7d5b1314280
    $ git rev-parse WHATEVER
    WHATEVER
    fatal: ambiguous argument 'WHATEVER': unknown revision or path not in the working tree.
    $ cp .git/{HEAD,WHATEVER}
    $ git rev-parse WHATEVER
    051ee1e7dd2c7b8bdc20f237eea3c7d5b1314280

I.e. we allow any arbitrary ref sitting in .git/, but presumably we
could just record the original string the user provided so that this
dies on OSX/Windows too:

    $ cp .git/{HEAD,Whatever}
    $ git rev-parse wHATEVER
    wHATEVER
    fatal: ambiguous argument 'wHATEVER': unknown revision or path not in the working tree.

But this may be a much deeper rabbit hole than I initially thought, I
was fishing to see if someone knew of a place in the code or WIP patch
that dealt with these special refs, but between the low-level machinery
& sha1_name.c (and others) there may be no easy one place to do this...

Re: Should "head" also work for "HEAD" on case-insensitive FS?

[Jeff King]

On Tue, Jul 04, 2017 at 10:24:30AM +0200, Ævar Arnfjörð Bjarmason wrote:

> I.e. we allow any arbitrary ref sitting in .git/, but presumably we
> could just record the original string the user provided so that this
> dies on OSX/Windows too:
> 
>     $ cp .git/{HEAD,Whatever}
>     $ git rev-parse wHATEVER
>     wHATEVER
>     fatal: ambiguous argument 'wHATEVER': unknown revision or path not in the working tree.
> 
> But this may be a much deeper rabbit hole than I initially thought, I
> was fishing to see if someone knew of a place in the code or WIP patch
> that dealt with these special refs, but between the low-level machinery
> & sha1_name.c (and others) there may be no easy one place to do this...

I think we talked at one point about allowing only [A-Z_] for top-level
refs. My recollection is that it generally seemed like a good idea, but
I don't think we ever had patches.

I think it would work to enforce it via check_refname_format(). That
would catch reading via dwim_ref(), which is what your example is
hitting. But it should also prevent people from writing ".git/foo" (or
worse, ".git/config") as a ref.

I do think that's the tip of the iceberg for case-sensitivity problems
with refs, though. Because packed-refs is case-sensitive, I think you
can create some pretty confusing states on case-insensitive filesystems.
For example:

  http://public-inbox.org/git/20150825052123.GA523@sigill.intra.peff.net/

Ultimately I think the path forward is to have a ref backend that
behaves uniformly (either because it avoids the filesystem, or because
it encodes around the differences). See:

  http://public-inbox.org/git/xmqqvb4udyf9.fsf@gitster.mtv.corp.google.com/

and its reply.

-Peff

Re: Should "head" also work for "HEAD" on case-insensitive FS?

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Ultimately I think the path forward is to have a ref backend that
> behaves uniformly (either because it avoids the filesystem, or because
> it encodes around the differences). See:
>
>   http://public-inbox.org/git/xmqqvb4udyf9.fsf@gitster.mtv.corp.google.com/
>
> and its reply.

Once Michael's packed-refs backend stabilizes, we may have a nice
calm period in the refs subsystem and I expect that this will become
a good medium-sized project for a contributor who does not have to 
be so experienced (but not a complete newbie).

It needs to:

 - add icase-files-backend, preferrably sharing as much code as the
   existing files-backend, in refs/.

 - design a mechanism to configure which refs backend to use at
   runtime; as this has to be done fairly early in the control flow,
   this will likely to use early configuration mechanism and will
   probably need to be done in the set-up code, but doing it lazy
   may even be nicer, as not all subcommands need access to refs.

Thanks for a pointer to the archive.

Re: Should "head" also work for "HEAD" on case-insensitive FS?

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Once Michael's packed-refs backend stabilizes, we may have a nice
> calm period in the refs subsystem and I expect that this will become
> a good medium-sized project for a contributor who does not have to 
> be so experienced (but not a complete newbie).
>
> It needs to:
>
>  - add icase-files-backend, preferrably sharing as much code as the
>    existing files-backend, in refs/.
>
>  - design a mechanism to configure which refs backend to use at
>    runtime; as this has to be done fairly early in the control flow,
>    this will likely to use early configuration mechanism and will
>    probably need to be done in the set-up code, but doing it lazy
>    may even be nicer, as not all subcommands need access to refs.
>
> Thanks for a pointer to the archive.

So here is an early WIP/illustration I did to see how involved such
a change would be, which should apply cleanly on top of 'pu'.

I was pleasantly surprised how cleanly refs/files-backend.c
separates the notion of "path" and "refname".  Only two functions,
files_reflog_path() and files_ref_path(), are responsible for taking
the refname and turning it to the pathname of an filesystem entity.
One one function, loose_fill_ref_dir(), is responsible for running
readdir() to find pathname, and turning the result into a refname.
So in theory, these three are the only things that need to know
about the "encoding".

The exact detail of the encoding used here is immaterial, but I just
used "encode uppercase letters and % as % followed by two hex",
which was simple enough.  Usual refs/heads/master and friends will
not have to be touched when encoded this way.  Perhaps the decoding
side should be tweaked so that uppercase letters it sees needs to be
downcased to avoid "refs/heads/Foo" getting returned as "Foo" branch,
as a "Foo" branch should have been encoded as "refs/heads/%46oo".

Having said that, this patch alone does not quite work yet.

 * In the repository discovery code, we have some logic that
   hard-codes the path in the directory (which is a candidate for
   being a repository) to check, like "refs/" and "HEAD".  In the
   attached illustration patch, files_path_encode() special cases
   "HEAD" so that it is not munged, which is a bit of ugly
   workaround for this.

 * I haven't figured out why, but what refs.c calls "pseudo refs"
   bypasses the files backend layer for some but not all operations,
   which causes t1405-main-ref-store to fail.  The test creates a
   "pseudo ref" FOO and then tries to remove it.  Creation seems to
   follow the files-backend.c and thusly goes through the escaping;
   refs.::refs_delete_ref() however does not consult files-backend.c
   and fails to find and delete .git/FOO, because the creation side
   encoded it as ".git/%46%4F%4F".

Michael is CC'ed as I thought it would be simpler to just ask about
the latter bullet point than digging it further myself ;-)

Thanks.

 refs/files-backend.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 56 insertions(+), 6 deletions(-)

diff --git a/refs/files-backend.c b/refs/files-backend.c
index 923e481e06..5bde77cbf8 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -23,6 +23,7 @@ struct ref_lock {
 struct files_ref_store {
 	struct ref_store base;
 	unsigned int store_flags;
+	int encode_names;
 
 	char *gitdir;
 	char *gitcommondir;
@@ -54,6 +55,9 @@ static struct ref_store *files_ref_store_create(const char *gitdir,
 	base_ref_store_init(ref_store, &refs_be_files);
 	refs->store_flags = flags;
 
+	/* git_config_get_bool("core.escapeLooseRefNames", &refs->encode_names); */
+	refs->encode_names = 1;
+
 	refs->gitdir = xstrdup(gitdir);
 	get_common_dir_noenv(&sb, gitdir);
 	refs->gitcommondir = strbuf_detach(&sb, NULL);
@@ -102,6 +106,49 @@ static struct files_ref_store *files_downcast(struct ref_store *ref_store,
 	return refs;
 }
 
+static void files_path_encode(struct files_ref_store *refs,
+			      struct strbuf *sb, const char *refname)
+{
+	if (!refs->encode_names || !strcmp(refname, "HEAD")) {
+		strbuf_addstr(sb, refname);
+	} else {
+		const char *cp;
+
+		for (cp = refname; *cp; cp++) {
+			int ch = *cp;
+			if (('A' <= ch && ch <= 'Z') || (ch == '%'))
+				strbuf_addf(sb, "%%%02x", ch);
+			else
+				strbuf_addch(sb, ch);
+		}
+	}
+}
+
+static int files_path_decode(struct files_ref_store *refs,
+			     struct strbuf *sb, const char *name, int namelen)
+{
+	if (!refs->encode_names) {
+		strbuf_add(sb, name, namelen);
+	} else {
+		size_t origlen = sb->len;
+
+		while (namelen--) {
+			int ch = *name++;
+
+			if (ch == '%') {
+				if (namelen < 2 || (ch = hex2chr(name)) < 0) {
+					strbuf_setlen(sb, origlen);
+					return -1;
+				}
+				namelen -= 2;
+				name += 2;
+			}
+			strbuf_addch(sb, ch);
+		}
+	}
+	return 0;
+}
+
 static void files_reflog_path(struct files_ref_store *refs,
 			      struct strbuf *sb,
 			      const char *refname)
@@ -118,15 +165,16 @@ static void files_reflog_path(struct files_ref_store *refs,
 	switch (ref_type(refname)) {
 	case REF_TYPE_PER_WORKTREE:
 	case REF_TYPE_PSEUDOREF:
-		strbuf_addf(sb, "%s/logs/%s", refs->gitdir, refname);
+		strbuf_addf(sb, "%s/logs/", refs->gitdir);
 		break;
 	case REF_TYPE_NORMAL:
-		strbuf_addf(sb, "%s/logs/%s", refs->gitcommondir, refname);
+		strbuf_addf(sb, "%s/logs/", refs->gitcommondir);
 		break;
 	default:
 		die("BUG: unknown ref type %d of ref %s",
 		    ref_type(refname), refname);
 	}
+	files_path_encode(refs, sb, refname);
 }
 
 static void files_ref_path(struct files_ref_store *refs,
@@ -136,15 +184,16 @@ static void files_ref_path(struct files_ref_store *refs,
 	switch (ref_type(refname)) {
 	case REF_TYPE_PER_WORKTREE:
 	case REF_TYPE_PSEUDOREF:
-		strbuf_addf(sb, "%s/%s", refs->gitdir, refname);
+		strbuf_addf(sb, "%s/", refs->gitdir);
 		break;
 	case REF_TYPE_NORMAL:
-		strbuf_addf(sb, "%s/%s", refs->gitcommondir, refname);
+		strbuf_addf(sb, "%s/", refs->gitcommondir);
 		break;
 	default:
 		die("BUG: unknown ref type %d of ref %s",
 		    ref_type(refname), refname);
 	}
+	files_path_encode(refs, sb, refname);
 }
 
 /*
@@ -174,7 +223,7 @@ static void loose_fill_ref_dir(struct ref_store *ref_store,
 	}
 
 	strbuf_init(&refname, dirnamelen + 257);
-	strbuf_add(&refname, dirname, dirnamelen);
+	files_path_decode(refs, &refname, dirname, dirnamelen);
 
 	while ((de = readdir(d)) != NULL) {
 		struct object_id oid;
@@ -185,7 +234,8 @@ static void loose_fill_ref_dir(struct ref_store *ref_store,
 			continue;
 		if (ends_with(de->d_name, ".lock"))
 			continue;
-		strbuf_addstr(&refname, de->d_name);
+		if (files_path_decode(refs, &refname, de->d_name, strlen(de->d_name)))
+			continue;
 		strbuf_addstr(&path, de->d_name);
 		if (stat(path.buf, &st) < 0) {
 			; /* silently ignore */

Fwd: Should "head" also work for "HEAD" on case-insensitive FS?

[Michael Haggerty]

Dang, I just noticed that I hit "reply" rather than "reply-to-all" on
the below email (stupid GMail default). Junio, your response to this
email accordingly went only to me.

Michael

---------- Forwarded message ----------
From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Mon, Jul 10, 2017 at 7:52 AM
Subject: Re: Should "head" also work for "HEAD" on case-insensitive FS?
To: Junio C Hamano <gitster@pobox.com>


On Fri, Jul 7, 2017 at 12:34 AM, Junio C Hamano <gitster@pobox.com> wrote:
> [...]
> The exact detail of the encoding used here is immaterial, but I just
> used "encode uppercase letters and % as % followed by two hex",
> which was simple enough.  Usual refs/heads/master and friends will
> not have to be touched when encoded this way.  Perhaps the decoding
> side should be tweaked so that uppercase letters it sees needs to be
> downcased to avoid "refs/heads/Foo" getting returned as "Foo" branch,
> as a "Foo" branch should have been encoded as "refs/heads/%46oo".
>
> Having said that, this patch alone does not quite work yet.
>
>  * In the repository discovery code, we have some logic that
>    hard-codes the path in the directory (which is a candidate for
>    being a repository) to check, like "refs/" and "HEAD".  In the
>    attached illustration patch, files_path_encode() special cases
>    "HEAD" so that it is not munged, which is a bit of ugly
>    workaround for this.
>
>  * I haven't figured out why, but what refs.c calls "pseudo refs"
>    bypasses the files backend layer for some but not all operations,
>    which causes t1405-main-ref-store to fail.  The test creates a
>    "pseudo ref" FOO and then tries to remove it.  Creation seems to
>    follow the files-backend.c and thusly goes through the escaping;
>    refs.::refs_delete_ref() however does not consult files-backend.c
>    and fails to find and delete .git/FOO, because the creation side
>    encoded it as ".git/%46%4F%4F".

I think the most natural thing would be to use different encoding
rules for pseudo-refs (references like "HEAD" and "FETCH_HEAD") and
for other references (those starting with "refs/").

Pseudo-refs (with the partial exception of "HEAD") are quite peculiar
beasts. They sometimes include other information besides the reference
value and IIRC the refs code doesn't have any idea how to write or
read those extra contents. I believe that "HEAD" is the only pseudo
ref for which reflogs are ever written. Pseudo-refs have to match
/[A-Z_]+/ (see https://github.com/git/git/blob/8b2efe2a0fd93b8721879f796d848a9ce785647f/refs.c#L169-L173),
so ISTM that there is no need to encode such references' filenames at
all. (It's possible that the pattern could be made even stricter, like
/[A-Z_]+HEAD/.) Moreover, IIRC, such references are never scanned for
(as in for-each-refs) but rather are always asked for by name. So
their names might never have to be *de*coded, either. On the other
hand, when trying to look them up, it would be a good idea to verify
that the requested name satisfies the above naming rule. Other than
that, I believe it would be preferable to leave pseudo-refs untouched
by your new encoding/decoding code.

Whereas other references are typically lower-case, so it makes sense
for lower-case letters to be the ones that are passed through
transparently in such references' filenames (as in your scheme).

But...since we are talking about introducing a new loose reference
filename encoding, I think it would be a good idea to address a couple
of related issues at the same time:

* Some filesystems natively use Unicode, and insist on a particular
Unicode normalization (NFC vs NFD), which might differ from the
"upstream" normalization. So such reference names get munged when
written as loose references. I'm not enough of an expert in Unicode to
know what the best solution is, except for the strong feeling that it
would require some cooperation from the rest of Git to ensure a good
user experience.

* Another bad effect of our current loose reference encoding is that
it prohibits references that D/F conflict with each other (like
"refs/heads/foo" and "refs/heads/foo/bar") because
"$GIT_DIR/refs/heads/foo" can't be a file and a directory at the same
time. Even if we don't want to support that, this problem also
prevents us from storing reflogs for deleted references, which is a
serious flaw. We could solve this problem by encoding "directory"
components of reference names differently than "leaf" components; for
example, the above references could be encoded as
"refs/heads.d/foo.ref" and "refs/heads.d/foo.d/bar.ref".

It'd be nice to solve all of these related problems at the same time,
because whatever encoding we choose now will have to be supported
forever.

Michael

Fwd: Should "head" also work for "HEAD" on case-insensitive FS?

[Junio C Hamano]

Heh, then I'll forward my response and we are even ;-)


---------- Forwarded message ----------
From: Junio C Hamano <gitster@pobox.com>
Date: Mon, Jul 10, 2017 at 10:48 AM
Subject: Re: Should "head" also work for "HEAD" on case-insensitive FS?
To: Michael Haggerty <mhagger@alum.mit.edu>


Michael Haggerty <mhagger@alum.mit.edu> writes:

> I think the most natural thing would be to use different encoding
> rules for pseudo-refs (references like "HEAD" and "FETCH_HEAD") and
> for other references (those starting with "refs/").
>
> Pseudo-refs (with the partial exception of "HEAD") are quite peculiar
> beasts....

I agree with the reasoning, but what I am worried about is that
their handling in the existing refs.c code may be leaky and/or
inconsistent.

What I saw was that a test have ended up with .git/%46%4F%4F when it
was told to create a ref "FOO" (which indicates that "FOO" was
passed to the files backend), which later failed to read it back
because the pseudo_ref handling refs.c wanted to see ".git/FOO" on
the reading side.

Perhaps it is only a bug in t/t1405-main-ref-store.sh?

> But...since we are talking about introducing a new loose reference
> filename encoding, ...

Yes, but that is an encoding detail I do not have to get involved
and folks with platform needs can add more on top---we need to make
sure that the places that encode and decode are identified in the
code first, and the things like "FOO is encoded upon writing because
files-backend is asked to write it, but not decoded because refs.c
thinks it is pseudo-ref and does not give a say to files-backend"
shouldn't be happening before we can start working on the details of
the encoding.  Making a conscious decision that pseudo-refs are left
as-is is OK, but we need to see both reading and writing side
following the same codepath to make that decision, which does not
seem to be the case in the current code.

Re: Fwd: Should "head" also work for "HEAD" on case-insensitive FS?

[Jeff King]

On Wed, Jul 26, 2017 at 05:49:47PM -0700, Junio C Hamano wrote:

> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
> > I think the most natural thing would be to use different encoding
> > rules for pseudo-refs (references like "HEAD" and "FETCH_HEAD") and
> > for other references (those starting with "refs/").
> >
> > Pseudo-refs (with the partial exception of "HEAD") are quite peculiar
> > beasts....
> 
> I agree with the reasoning, but what I am worried about is that
> their handling in the existing refs.c code may be leaky and/or
> inconsistent.
> 
> What I saw was that a test have ended up with .git/%46%4F%4F when it
> was told to create a ref "FOO" (which indicates that "FOO" was
> passed to the files backend), which later failed to read it back
> because the pseudo_ref handling refs.c wanted to see ".git/FOO" on
> the reading side.
> 
> Perhaps it is only a bug in t/t1405-main-ref-store.sh?

An interesting related issue for pseudo-refs: if you encode HEAD as
.git/%48%45%41%44, how will we recognize that directory as a git
repository? Detecting (and doing a sanity check on) "HEAD" is one of the
key mechanisms for deciding whether we are in a git repository.

Obviously an older version of git that doesn't know about the new
encoding scheme wouldn't work on this repository anyway. But:

  1. It should say "this is a git repo, but not a vintage I understand".
     Not "this isn't a git repo, I'll keep looking".

  2. How does a git version of the correct vintage decide "this is a git
     repo, so I'll check its config for extensions.refBackend, and a-ha,
     they _do_ have a HEAD". There's a chicken-and-egg problem.

Obviously for (2) we could teach that mechanism to look for the encoded
HEAD file, too. But this is just one backend. What about a reftable or
other non-filesystem store that keeps "HEAD" inside a file?

I kind of wonder if more exotic ref storage backends should always just
place a dummy "HEAD" file that is enough to bootstrap the "this is a git
repo" process (for both new and old versions).

This is orthogonal to the rest of the pseudo-refs discussion, but just
something I thought of while reading the thread.

-Peff

Re: Fwd: Should "head" also work for "HEAD" on case-insensitive FS?

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Wed, Jul 26, 2017 at 05:49:47PM -0700, Junio C Hamano wrote:
>
>> What I saw was that a test have ended up with .git/%46%4F%4F when it
>> was told to create a ref "FOO" (which indicates that "FOO" was
>> passed to the files backend), which later failed to read it back
>> because the pseudo_ref handling refs.c wanted to see ".git/FOO" on
>> the reading side.
>> 
>> Perhaps it is only a bug in t/t1405-main-ref-store.sh?
>
> An interesting related issue for pseudo-refs: if you encode HEAD as
> .git/%48%45%41%44, how will we recognize that directory as a git
> repository?

Yes, that is a valid point.  I may have forgot to explain why the
sample change in my message upthread special cases "HEAD" and leaves
it untouched, but it is done for this exact reason.

>   1. It should say "this is a git repo, but not a vintage I understand".
>      Not "this isn't a git repo, I'll keep looking".
>
>   2. How does a git version of the correct vintage decide "this is a git
>      repo, so I'll check its config for extensions.refBackend, and a-ha,
>      they _do_ have a HEAD". There's a chicken-and-egg problem.

Yes, exactly.

Re: Should "head" also work for "HEAD" on case-insensitive FS?

[Kenneth Hsu]

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.