From: Marc Strapetz Date: Wed, 25 Nov 2015 16:27:50 GMT Subject: Re: branch --set-upstream-to unexpectedly fails with "starting point ... is no branch" Message-ID: <5655E186.8060205@syntevo.com> In-Reply-To: <12A15BA3-11C2-426A-87D6-421BA9708A51@dwim.me> On 24.11.2015 17:58, Carlos Martín Nieto wrote: > > On 23 Nov 2015, at 19:59, Marc Strapetz wrote: > >> On 23.11.2015 18:04, Carlos Martín Nieto wrote: >>> Hello Mark, >>> >>> On 23 Nov 2015, at 12:04, Marc Strapetz wrote: >>> >>>> There is a strange "branch --set-upstream-to" failure for "clones" which haven't been created using "git clone" but constructed using "git init", "git remote add" and "git fetch". >>>> >>>> Following script first creates a "main" repository and then constructs the clone. Finally, in the clone branches origin/1 and origin/2 will be present, however it's not possible to invoke "git branch --set-upstream-to" for origin/2 (it works fine for origin/1). >>>> >>>> I guess the behavior is related to following line in .git/config: >>>> >>>> fetch = refs/heads/1:refs/remotes/origin/1 >>>> >>>> However, I don't understand what's the problem for Git here? Definitely the error "starting point 'origin/2' is not a branch" is wrong. >>>> >>> >>> That is indeed the issue. The configuration which is stored in the configuration is a remote+branch pair. If there is no fetch refspec configured which would create the ‘origin/2’ remote-tracking branch, the command does not know which remote and branch that would correspond to. >> >> Thanks, Carlos, I understand now. >> >> My goal is to have a clone which will only fetch specific branches, so I guess I have to stick with "refs/heads/1:refs/remotes/origin/1" for the beginning and for every new branch X add another "refs/heads/X:refs/remotes/origin/X"? Or is there a better way? > > If you want fine-grained control over what gets downloaded, you’ll need to restrict either the configured refspecs or the ones which git-fetch gets. Thanks, Carlos. I'll take this approach as it's the safer one. -Marc