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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 9, 2013, 14:44 UTC
Message-ID: <xmqqr4cy5a2z.fsf@gitster.dls.corp.google.com>
In-Reply-To: <5425F66B510F423EA685BCEF40EF8FA7@PhilipOakley>

"Philip Oakley" <philipoakley@iee.org> writes:

Show 11 quoted lines

> 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.

Show 5 quoted lines

> 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.