"Philip Oakley" <philipoak...@iee.org> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html