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

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