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
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
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).
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
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
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
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
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
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
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
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
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
12 matches
Mail list logo