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

2013-09-09 Thread Junio C Hamano
Philip Oakley philipoak...@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

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

2013-09-09 Thread Andreas Krey
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

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

2013-09-09 Thread Philip Oakley
From: Junio C Hamano gits...@pobox.com Sent: Monday, September 09, 2013 3:44 PM Philip Oakley philipoak...@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).

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

2013-09-09 Thread Junio C Hamano
Philip Oakley philipoak...@iee.org 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 41ccb18028d1cb6516251e94cef1cd5cb3f0bcb5

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

2013-09-08 Thread Junio C Hamano
Philip Oakley philipoak...@iee.org 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

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

2013-09-08 Thread Philip Oakley
From: Junio C Hamano gits...@pobox.com Sent: Sunday, September 08, 2013 6:35 PM Philip Oakley philipoak...@iee.org 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

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

2013-09-07 Thread Junio C Hamano
Philip Oakley philipoak...@iee.org writes: From: Junio C Hamano gits...@pobox.com Philip Oakley philipoak...@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

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

2013-09-07 Thread Philip Oakley
From: Junio C Hamano gits...@pobox.com Sent: Saturday, September 07, 2013 4:50 PM Philip Oakley philipoak...@iee.org writes: From: Junio C Hamano gits...@pobox.com Philip Oakley philipoak...@iee.org writes: Does this have any impact on the alleged bug in `git bundle --all` (which can then be

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

2013-09-06 Thread 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

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

2013-09-06 Thread Philip Oakley
From: Andreas Krey a.k...@gmx.de 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

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

2013-09-06 Thread Junio C Hamano
Philip Oakley philipoak...@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

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

2013-09-06 Thread Philip Oakley
From: Junio C Hamano gits...@pobox.com Philip Oakley philipoak...@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