From: "Junio C Hamano" <gitster@xxxxxxxxx>
Sent: Monday, September 09, 2013 3:44 PM
"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.
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
--
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