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 r
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
Дилян
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 --
Am 01.07.2013 18:46, schrieb Junio C Hamano:
Stefan Näwe stefan.na...@atlas-elektronik.com 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
Stefan Näwe stefan.na...@atlas-elektronik.com 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
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/releases/)
to communicate between the 'branch integrator
Stefan Näwe stefan.na...@atlas-elektronik.com 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
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
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 the ref in
refs/releases
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/releases/)
to communicate between the 'branch integrator
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' refs (in
refs/releases/)
to communicate between
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/) ?
Background: At $dayjob we're using some kind of 'hidden' refs
12 matches
Mail list logo