From: "Junio C Hamano" <gitster@xxxxxxxxx>
Sent: Sunday, September 08, 2013 6:35 PM
"Philip Oakley" <philipoakley@xxxxxxx> writes:
What I observed was that all the clones had the same HEAD problem,
which I think comes from clone.c: guess_remote_head().
Yes. They share "having to guess" property because their data
source does not tell them.
My quick look at clone.c suggested to me that there would be a lot of
commonality between the bundle data stream and the transport streams
(identical?), and it was just a case of adding into the bundle data
the same HEAD symref indication that would solve the normal clone
problem (including backward compatibility). Is that a reasonable
assesssment?
You need to find a hole in the existing readers to stick the new
information in a way that do not break existing readers but allow
updated readers to extract that information. That is exactly what
we did when we added the protocol capability. I do not offhand
think an equivalent hole exists in the bundle file format.
--
I've been rummaging about as to options.
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.
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.
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