Re: [PATCH 0/3] Unconfuse git clone when two branches at are HEAD.

From: "Junio C Hamano" <redacted>
Sent: Sunday, September 08, 2013 6:35 PM

"Philip Oakley" [off-list ref] writes:

quoted

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.

quoted

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