"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/
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
regu
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 th
"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.
>
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 te
"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 w
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 bun
"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 HEA
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
"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 do
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
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
tra
12 matches
Mail list logo
