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

From: Philip Oakley <philipoakley@iee.org>
Date: Sep 7, 2013, 19:19 UTC
Message-ID: <531DBE1FF66D4356AEE6AEE5C2FE9389@PhilipOakley>
In-Reply-To: <xmqqwqmsvdfh.fsf@gitster.dls.corp.google.com>

From: "Junio C Hamano" <gitster@pobox.com>
Sent: Saturday, September 07, 2013 4:50 PM

Show 32 quoted lines

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

I was having a quick look at the different bundle/clone routes and tried out (on 1.8.1.msysgit.1) the following script to see the differences (probably word wrap damaged):

--- cd /c/ # if on Windows to be at the top of c:/ mkdir gitBundleTest1 cd gitBundleTest1 git init echo AAA >a.txt git add a.txt git commit -mfirst git checkout -b feature git checkout -b zulu # does this, alphabetically after master, change anything? git status # observe on 'feature' branch # one repo, one file, one commit, two branches

# test the bundle - clone transfer git bundle create Repo.bundle --all git clone Repo.bundle ../gitBundleTest2 cd ../gitBundleTest2 git status # observe on wrong branch

# back to original repo cd ../gitBundleTest1 # test the direct clone transfer git clone . ../gitBundleTest3 cd ../gitBundleTest3 git status # observe on wrong branch again

# back to top level (wherever that is on Msys Windows ;-) cd .. pwd # test the git protocol clone transfer # it's file:// followed by abolute path /path/to/dir so ... # but note msys windows /c/ git clone file:///c/gitBundleTest1 ./gitBundleTest4 cd ./gitBundleTest4 git status # observe on wrong branch again

cd ~ # return home ---

What I observed was that all the clones had the same HEAD problem, which I think comes from clone.c: guess_remote_head().

When I looked in the Repo.bundle file I saw the refs/heads/* listed in alphabetic order followed by HEAD, all with the same sha1 (in this case), followed by PACK and then the binary data.

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?

Philip