Re: [PATCH 0/3] Unconfuse git clone when two branches at are HEAD.

"Philip Oakley" [off-list ref] writes:

One is to extend the ref format such that
 <sha1> refs/heads/Test:HEAD
would be considered a valid indicator of a symref relationship
(i.e. using the typical 'colon' style). It would be appended after the
regular refs, so all the existing refs are still transported.

The point is that while it produces an error, it doesn't stop the
cloning, and the error message
"error: * Ignoring funny ref 'refs/remotes/origin/Test:HEAD' locally"
gives a pretty clear statement of intent to those with older versions
of git.

Cute.  If it does not stop any of these:

        git ls-remote such.bundle
	git clone such.bundle
        git fetch such.bundle
	git fetch such.bundle master ;# if 'master' branch is in it
        git ls-remote such.bundle
        git ls-remote such.bundle master ;# if 'master' branch is in it

even if some of them may give error messages, I think that may be a
workable escape hatch.

Another alternative is to add an additional name space (e.g.)
  <sha1> refs/remotes/origin/HEAD/Test
which would simply be an extra directory layer that reflects where the
HEAD should have been. Though this namespace example has the D/F
conflict.

I'd rather not go this route.  Allowing refs/heads/master and local
branches that forked from it in refs/heads/master/{a,b,c,...} could
be a potentially useful future enhancement, and this approach will
close the door for it.