Re: git clone -b

2017-05-08 Thread Jeff King
On Mon, May 08, 2017 at 08:30:49AM +0200, Дилян Палаузов wrote: > why do these work: > > git clone --bare -b 3.5 https://github.com/python/cpython A > git clone -b 3.6 A B >From the description of --bare in "git help clone": [...]the branch heads at the remo

git clone -b

2017-05-07 Thread Дилян Палаузов
Hello, why do these work: git clone --bare -b 3.5 https://github.com/python/cpython A git clone -b 3.6 A B git clone -b 3.5 https://github.com/python/cpython C but these not: git clone -b 3.6 C D git clone --no-local -b 3.6 C D with git version 2.12.2.89.g49800c940? Regards Дилян

Re: git clone -b

2013-07-03 Thread Jeff King
On Mon, Jul 01, 2013 at 01:49:37PM -0400, Phil Hord wrote: > It would be nice to support more generic specs for the --branch > switch. But it is complicated because the refs have not been fetched > yet during the clone, and so normal refs operations -- which expect to > work on a local repository

Re: git clone -b

2013-07-02 Thread Junio C Hamano
Stefan Näwe writes: >> While I wasn't paying much attention to this, I vaguely recall that >> people pointed out that using a fresh clone every time may not be >> what you want to do in the first place, and I happen to agree with >> them (and that is why I am not very much interested in this topi

Re: git clone -b

2013-07-01 Thread Stefan Näwe
Am 01.07.2013 18:46, schrieb Junio C Hamano: > Stefan Näwe writes: > >>> Is there any reason why 'git clone -b' only takes a branch (from >>> refs/heads/) >>> or a tag (from refs/tags/) ? > > Because they are common enough, and doing the sam

Re: git clone -b

2013-07-01 Thread Phil Hord
It would be nice to support more generic specs for the --branch switch. But it is complicated because the refs have not been fetched yet during the clone, and so normal refs operations -- which expect to work on a local repository -- do not work. So, the ref is looked up locally from a list in exp

Re: git clone -b

2013-07-01 Thread Junio C Hamano
Stefan Näwe writes: >> Is there any reason why 'git clone -b' only takes a branch (from refs/heads/) >> or a tag (from refs/tags/) ? Because they are common enough, and doing the same for an arbitrary object is just as easy to do something like: git clone -

Re: git clone -b

2013-07-01 Thread Stefan Näwe
Am 28.06.2013 13:59, schrieb Stefan Näwe: > Hi there! > > Is there any reason why 'git clone -b' only takes a branch (from refs/heads/) > or a tag (from refs/tags/) ? > > Background: At $dayjob we're using some kind of 'hidden' refs (in > refs/r

Re: git clone -b

2013-06-28 Thread Stefan Näwe
Am 28.06.2013 14:18, schrieb Fredrik Gustafsson: > On Fri, Jun 28, 2013 at 01:59:51PM +0200, Stefan Näwe wrote: >> Hi there! >> >> Is there any reason why 'git clone -b' only takes a branch (from refs/heads/) >> or a tag (from refs/tags/) ? >> >>

Re: git clone -b

2013-06-28 Thread Fredrik Gustafsson
On Fri, Jun 28, 2013 at 01:59:51PM +0200, Stefan Näwe wrote: > Hi there! > > Is there any reason why 'git clone -b' only takes a branch (from refs/heads/) > or a tag (from refs/tags/) ? > > Background: At $dayjob we're using some kind of 'hidden' r

Re: git clone -b

2013-06-28 Thread Stefan Näwe
Am 28.06.2013 13:59, schrieb Stefan Näwe: > Hi there! > > Is there any reason why 'git clone -b' only takes a branch (from refs/heads/) > or a tag (from refs/tags/) ? > > Background: At $dayjob we're using some kind of 'hidden' refs (in > refs/r

git clone -b

2013-06-28 Thread Stefan Näwe
Hi there! Is there any reason why 'git clone -b' only takes a branch (from refs/heads/) or a tag (from refs/tags/) ? Background: At $dayjob we're using some kind of 'hidden' refs (in refs/releases/) to communicate between the 'branch integrator' (who creates