Re: [PATCH 0/3] Unconfuse git clone when two branches at are HEAD.
"Philip Oakley" writes: > 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 > 41ccb18028d1cb6516251e94cef1cd5cb3f0bcb5refs/heads/Test:HEAD > > It's only the clone that barfs (so far) (which could be 'fixed'). You cannot 'fix' the ones deployed in the wild, but I think saying "funny ref" and not aborting is a good compromise. The updated documentation for bundle can mention that error message and explain that the older version of "clone" will say that in what situation. I didn't notice it the first time, but I think the above would read better and match what has been discussed on the on-the-wire format to swap the order, i.e. use "HEAD:refs/heads/Test" to mean "HEAD is a symref that points at the Test branch". > 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. Yes, that is a sensible check. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Unconfuse git clone when two branches at are HEAD.
From: "Junio C Hamano" Sent: Monday, September 09, 2013 3:44 PM "Philip Oakley" writes: One is to extend the ref format such that 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 41ccb18028d1cb6516251e94cef1cd5cb3f0bcb5refs/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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Unconfuse git clone when two branches at are HEAD.
On Mon, 09 Sep 2013 07:44:04 +, Junio C Hamano wrote:
...
> I'd rather not go this route. Allowing refs/heads/master and local
> branches that forked from it in refs/heads/master/{a,b,c,...} could
> be a potentially useful future enhancement,
Want! We're currently going the route of naming the branches
master
feature/master
feature/subfeature/master
to allow feature/subfeature/topic, and feature/subfeature in the first place.
(Other hierarchy separator candidates were ugly, shell-unwieldy, already
commonly used within branch names, or illegal.)
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds
Date: Fri, 22 Jan 2010 07:29:21 -0800
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Unconfuse git clone when two branches at are HEAD.
"Philip Oakley" writes:
> One is to extend the ref format such that
> 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.
> Another alternative is to add an additional name space (e.g.)
>refs/remotes/origin/HEAD/Test
> which would simply be an extra directory layer that reflects where the
> HEAD should have been. Though this namespace example has the D/F
> conflict.
I'd rather not go this route. Allowing refs/heads/master and local
branches that forked from it in refs/heads/master/{a,b,c,...} could
be a potentially useful future enhancement, and this approach will
close the door for it.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Unconfuse git clone when two branches at are HEAD.
From: "Junio C Hamano" Sent: Sunday, September 08, 2013 6:35 PM "Philip Oakley" writes: What I observed was that all the clones had the same HEAD problem, which I think comes from clone.c: guess_remote_head(). Yes. They share "having to guess" property because their data source does not tell them. 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? You need to find a hole in the existing readers to stick the new information in a way that do not break existing readers but allow updated readers to extract that information. That is exactly what we did when we added the protocol capability. I do not offhand think an equivalent hole exists in the bundle file format. -- I've been rummaging about as to options. One is to extend the ref format such that 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. Another alternative is to add an additional name space (e.g.) refs/remotes/origin/HEAD/Test which would simply be an extra directory layer that reflects where the HEAD should have been. Though this namespace example has the D/F conflict. Philip -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Unconfuse git clone when two branches at are HEAD.
"Philip Oakley" writes: > What I observed was that all the clones had the same HEAD problem, > which I think comes from clone.c: guess_remote_head(). Yes. They share "having to guess" property because their data source does not tell them. > 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? You need to find a hole in the existing readers to stick the new information in a way that do not break existing readers but allow updated readers to extract that information. That is exactly what we did when we added the protocol capability. I do not offhand think an equivalent hole exists in the bundle file format. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Unconfuse git clone when two branches at are HEAD.
From: "Junio C Hamano" Sent: Saturday, September 07, 2013 4:50 PM "Philip Oakley" writes: From: "Junio C Hamano" "Philip Oakley" 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Unconfuse git clone when two branches at are HEAD.
"Philip Oakley" writes: > From: "Junio C Hamano" >> "Philip Oakley" 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Unconfuse git clone when two branches at are HEAD.
From: "Junio C Hamano" "Philip Oakley" 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. Philip -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Unconfuse git clone when two branches at are HEAD.
"Philip Oakley" 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Unconfuse git clone when two branches at are HEAD.
From: "Andreas Krey" Ok, here are some patches that make git actually check out the current remote branch when cloning. Up to now this failed when there were two branches that pointed to the HEAD commit of the remote repo, and git clone would sometimes choose the wrong one as the HEAD ref isn't transmitted in all transport. Stuff the HEAD ref into the capability list (assuming refs are clean enough to do that w/o escaping), and read them out on the other side. All other things were thankfully already in place. Two of the patches have Junio in the From as they are essentially his. Andreas -- 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? Philip -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Unconfuse git clone when two branches at are HEAD.
Ok, here are some patches that make git actually check out the current remote branch when cloning. Up to now this failed when there were two branches that pointed to the HEAD commit of the remote repo, and git clone would sometimes choose the wrong one as the HEAD ref isn't transmitted in all transport. Stuff the HEAD ref into the capability list (assuming refs are clean enough to do that w/o escaping), and read them out on the other side. All other things were thankfully already in place. Two of the patches have Junio in the From as they are essentially his. Andreas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
