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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 7, 2013, 15:50 UTC
Message-ID: <xmqqwqmsvdfh.fsf@gitster.dls.corp.google.com>
In-Reply-To: <94A71512041A4F9BB402474DB385E310@PhilipOakley>

"Philip Oakley" <philipoakley@iee.org> writes:

Show 20 quoted lines

> From: "Junio C Hamano" <gitster@pobox.com>
>> "Philip Oakley" <philipoakley@iee.org> writes:
>>
>>> Does this have any impact on the alleged bug in `git bundle --all`
>>> (which can then be cloned from) where the current HEAD ref wasn't
>>> included in the bundle? Or am I mis-remembering?
>>
>> Not "current HEAD ref", but "git clone" will fail to check out from
>> a bundle that does not include HEAD ref (it is easy to just say
>> "reset --hard master" or whatever after it, though).
>>
>> I think I suggested to update "git bundle" to include HEAD when
>> there is no HEAD specified some time ago, but I do not think anybody
>> was interested, so this may be a non-issue.
>>
> Just had a quick look at a very quick test repo (10 objects, 2
> branches) and the bundle file does contain the HEAD ref, but again it
> has the two ref/heads/* are better than one problem, in that the clone
> from the bundle checks out master, whilst the source repo has feature
> checked out.

I do not think the bundle header records symref any differently from other refs, so a HEAD that points at a commit that is at the tip of more than one ref needs to be guessed at the extraction end, just like the network-transfer case discussed in this thread.

But this thread is not about updating the current bundle format to a new one, so any of the updates proposed in these patches will not affect it.