"Philip Oakley" <philipoakley@xxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html