git clone -b

git clone -b

[Дилян Палаузов]

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

[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 remote are copied directly to
  corresponding local branch heads, without mapping them to
  refs/remotes/origin/. When this option is used, neither
  remote-tracking branches nor the related configuration variables are
  created.

So because the upstream has a refs/heads/3.6 branch, so too does the
bare clone "A". And thus when you clone it asking for that branch, Git
can find it.

But in your non-bare example:

> 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

In the non-bare clone C, there is no local 3.6 branch. You only have the
remote-tracking branch refs/remotes/origin/3.6. So when you try to clone
from it, Git can't find the branch:

  $ git clone -b 3.6 C D
  Cloning into 'D'...
  fatal: Remote branch 3.6 not found in upstream origin
  fatal: The remote end hung up unexpectedly

It works if you create a local branch based on upstream's branch:

  $ git -C C checkout 3.6
  Branch 3.6 set up to track remote branch 3.6 from origin.
  Switched to a new branch '3.6'

  $ git clone -b 3.6 C D
  Cloning into 'D'...
  done.

-Peff

git clone -b

[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 the ref in refs/releases/)
and the 'build master' who wants to build that ref. 

It would be a little easier if the build master could simply say

  git clone -b refs/releases/the-release-for-today URL

instead of: git clone... ; cd ... ; git fetch... ; git checkout....

Any answer or even a better idea to solve that is appreciated.

Stefan
-- 
----------------------------------------------------------------
/dev/random says: Second star to the right & straight on till morning...
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"

Re: git clone -b

[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/releases/)
> to communicate between the 'branch integrator' (who creates the ref in refs/releases/)
> and the 'build master' who wants to build that ref. 
> 
> It would be a little easier if the build master could simply say
> 
>   git clone -b refs/releases/the-release-for-today URL
> 
> instead of: git clone... ; cd ... ; git fetch... ; git checkout....
> 
> Any answer or even a better idea to solve that is appreciated.
> 
> Stefan
> 

Oh, and while at it:

This doesn't look/feel right:

  $ git clone -b refs/heads/master git/.git other-git
  Cloning into 'other-git'...
  fatal: Remote branch refs/heads/master not found in upstream origin
  fatal: The remote end hung up unexpectedly

(where git is git's git which definitely has refs/heads/master...)

Stefan
-- 
----------------------------------------------------------------
/dev/random says: In God we trust; all else we walk through.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"

Re: git clone -b

[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 (in refs/releases/)
> to communicate between the 'branch integrator' (who creates the ref in refs/releases/)
> and the 'build master' who wants to build that ref. 
> 
> It would be a little easier if the build master could simply say
> 
>   git clone -b refs/releases/the-release-for-today URL
> 
> instead of: git clone... ; cd ... ; git fetch... ; git checkout....
> 
> Any answer or even a better idea to solve that is appreciated.
> 
> Stefan

I don't understand what the alternative should be. You can't look in
/refs/* because there's a lot of other stuff like bisect/remotes etc.
there.

Of course you could add to also look in /refs/releases/ but as I
understand you that a special solution for your company. Why should all
git users have that addition?

Two questions about your setup:

	1. Why do you always clone your repository? To me clone is a one
	time operation.

	2. Why don't you tag your releases with an ordinary tag?

-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iveqy@iveqy.com

Re: git clone -b

[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/) ?
>>
>> 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/)
>> and the 'build master' who wants to build that ref. 
>>
>> It would be a little easier if the build master could simply say
>>
>>   git clone -b refs/releases/the-release-for-today URL
>>
>> instead of: git clone... ; cd ... ; git fetch... ; git checkout....
>>
>> Any answer or even a better idea to solve that is appreciated.
>>
>> Stefan
> 
> I don't understand what the alternative should be. You can't look in
> /refs/* because there's a lot of other stuff like bisect/remotes etc.
> there.

Well, I tell clone exactly what I want. There is no reason try something
from refs/*.
 
> Of course you could add to also look in /refs/releases/ but as I
> understand you that a special solution for your company. Why should all
> git users have that addition?

It wouldn't hurt, IMHO. Maybe it would even make sense to allow any SHA-1
to be passed to '-b'.
 
> Two questions about your setup:
> 
> 	1. Why do you always clone your repository? To me clone is a one
> 	time operation.

We would use 'git archive' if that would be submodule-aware...

> 	2. Why don't you tag your releases with an ordinary tag?

Because we use that 'refs/release' thing as a hidden ref that other
developers will not see when they fetch (unless they are told to checkout
that particular ref).

Think of using this similar to the way github uses refs/pull/*/{head,merge} 
for their pull request mechanism.

Stefan
-- 
----------------------------------------------------------------
/dev/random says: The Definition of an Upgrade: Take old bugs out, put new ones in.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"

Re: git clone -b

[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/releases/)
> to communicate between the 'branch integrator' (who creates the ref in refs/releases/)
> and the 'build master' who wants to build that ref. 
> 
> It would be a little easier if the build master could simply say
> 
>   git clone -b refs/releases/the-release-for-today URL
> 
> instead of: git clone... ; cd ... ; git fetch... ; git checkout....
> 
> Any answer or even a better idea to solve that is appreciated.
> 
> Stefan
> 

Anyone?

Thanks,
  Stefan
-- 
----------------------------------------------------------------
/dev/random says: Some people like learning Eskimo, but I can't get Inuit.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"

Re: git clone -b

[Junio C Hamano]

Stefan Näwe <stefan.naewe@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 -n
        git checkout $an_arbitrary_commit_object_name^0

>> 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/)
>> and the 'build master' who wants to build that ref. 

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 topic).

Re: git clone -b

[Stefan Näwe]

Am 01.07.2013 18:46, schrieb Junio C Hamano:
> Stefan Näwe <stefan.naewe@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 -n
>         git checkout $an_arbitrary_commit_object_name^0

OK. I wasn't aware of '-n' for 'git clone'. Thanks.

> 
>>> 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/)
>>> and the 'build master' who wants to build that ref. 
> 
> 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 topic).
 
As I said: We'd be using 'git archive --remote...' if that was
submodule-aware.

Thanks,
  Stefan
-- 
----------------------------------------------------------------
/dev/random says: Circular Definition: see Definition, Circular.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"

Re: git clone -b

[Junio C Hamano]

Stefan Näwe <stefan.naewe@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 much interested in this topic).
>  
> As I said: We'd be using 'git archive --remote...' if that was
> submodule-aware.

That would still have to transfer full material enough to populate
the working tree for a single revision.  I was wondering why "clone
once, and then update incrementally with 'fetch && reset --hard' &&
clean'" is not used, if the tree is for a build-bot.

Re: git clone -b

[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 expected locations after fetching the remote
refs but before the clone occurs.  The remote refs which are fetched
is not configurable during clone, and so only 'refs/heads/*' is
fetched for non-mirrors.

I was able to tweak git-clone to fetch the remote ref when I hacked
builtin/clone.c to check in 'refs' and also to extend the refspec to
something more broad ("+refs/*:refs/remotes/origin/*"), but this is
not a workable solution.  But there probably is a more correct way
than the hack I tried.

Phil

Re: git clone -b

[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 -- do not work.  So, the ref is looked up
> locally from a list in expected locations after fetching the remote
> refs but before the clone occurs.  The remote refs which are fetched
> is not configurable during clone, and so only 'refs/heads/*' is
> fetched for non-mirrors.

I think there are two problems:

  1. Our find_remote_branch function implements only half of the regular
     ref_rev_parse_rules (heads and tags). Fixing that to make "-b
     refs/heads/master" work is pretty easy. Patch is below.

  2. When we give a ref that is not going to be fetched, we should
     fetch it explicitly. It looks like --single-branch tries to do
     this, but only handles tags. I am not sure what a non-single-branch
     would want to do (since you are effectively overriding the
     default refspecs).

     So even with the patch, doing "clone -b refs/foo/bar" does not
     quite work.

diff --git a/builtin/clone.c b/builtin/clone.c
index 14b1323..5984303 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -433,24 +433,24 @@ static struct ref *find_remote_branch(const struct ref *refs, const char *branch
 	raise(signo);
 }
 
-static struct ref *find_remote_branch(const struct ref *refs, const char *branch)
+static struct ref *find_remote_branch(const struct ref *refs, const char *name)
 {
-	struct ref *ref;
-	struct strbuf head = STRBUF_INIT;
-	strbuf_addstr(&head, "refs/heads/");
-	strbuf_addstr(&head, branch);
-	ref = find_ref_by_name(refs, head.buf);
-	strbuf_release(&head);
-
-	if (ref)
-		return ref;
-
-	strbuf_addstr(&head, "refs/tags/");
-	strbuf_addstr(&head, branch);
-	ref = find_ref_by_name(refs, head.buf);
-	strbuf_release(&head);
-
-	return ref;
+	int len = strlen(name);
+	const char **p;
+
+	for (p = ref_rev_parse_rules; *p; p++) {
+		struct ref *ref;
+
+		ref = find_ref_by_name(refs, mkpath(*p, len, name));
+		if (ref)
+			/*
+			 * optionally check for and complain about ambiguity
+			 * here, like dwim_ref does
+			 */
+			return ref;
+	}
+
+	return NULL;
 }
 
 static struct ref *wanted_peer_refs(const struct ref *refs,