From: "Junio C Hamano" <gitster@xxxxxxxxx>
Sent: Saturday, September 07, 2013 4:50 PM
"Philip Oakley" <philipoakley@xxxxxxx> writes:
From: "Junio C Hamano" <gitster@xxxxxxxxx>
"Philip Oakley" <philipoakley@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html