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

From: Philip Oakley <philipoakley@iee.org>
Date: Sep 9, 2013, 22:20 UTC
Message-ID: <CBB3BFF2B74D4A768238512FBF1CD6E7@PhilipOakley>
In-Reply-To: <xmqqr4cy5a2z.fsf@gitster.dls.corp.google.com>

From: "Junio C Hamano" <gitster@pobox.com>
Sent: Monday, September 09, 2013 3:44 PM

Show 27 quoted lines

> "Philip Oakley" <philipoakley@iee.org> 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