"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.
On Mon, 09 Sep 2013 07:44:04 +0000, Junio C Hamano wrote:
...
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,
Want! We're currently going the route of naming the branches
master
feature/master
feature/subfeature/master
to allow feature/subfeature/topic, and feature/subfeature in the first place.
(Other hierarchy separator candidates were ugly, shell-unwieldy, already
commonly used within branch names, or illegal.)
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
From: "Junio C Hamano" <redacted>
Sent: Monday, September 09, 2013 3:44 PM
"Philip Oakley" [off-list ref] writes:
quoted
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.
These look to work OK. Not sure If I've properly covered all the
options.
A nice feature is that ls-remote will find the fake ref !
$ git ls-remote /c/gitBundleTest1/RepoHEADnomaster.bundle Test:HEAD
41ccb18028d1cb6516251e94cef1cd5cb3f0bcb5 refs/heads/Test:HEAD
It's only the clone that barfs (so far) (which could be 'fixed').
Obviously, if it can be made to work, one check would be that the two
refs (HEAD and refs/heads/wherever) point to the came commit before
generating the HEAD symref.
Philip