# branch --set-upstream-to unexpectedly fails with "starting point ... is no branch" 5 messages from 2015-11-23 to 2015-11-25. Participants: Marc Strapetz, Carlos Martín Nieto. Thread: https://gitlist.dev/t/40857 ## Marc Strapetz, 2015-11-23 11:04 Subject: branch --set-upstream-to unexpectedly fails with "starting point ... is no branch" Message-ID: <5652F2D2.3050902@syntevo.com> URL: https://gitlist.dev/e/5652F2D2.3050902%40syntevo.com ``` 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. $ git --version git version 2.5.0.windows.1 $ cd /tmp/gittest $ mkdir main $ cd main $ git init $ touch file $ git add file $ git commit -m "import" $ git branch 1 $ git branch 2 $ git branch 1 2 * master $ cd /tmp/gittest $ mkdir clone $ cd clone $ git init Initialized empty Git repository in /tmp/gittest/clone/.git/ $ git remote add origin /tmp/gittest/main $ git config remote.origin.fetch refs/heads/1:refs/remotes/origin/1 $ git fetch origin remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From /tmp/gittest/main * [new branch] 1 -> origin/1 $ git fetch origin refs/heads/2:refs/remotes/origin/2 From /tmp/gittest/main * [new branch] 2 -> origin/2 $ git branch --no-track 2 refs/remotes/origin/2 $ git branch 2 # HERE COMES THE STRANGE FAILURE: $ git branch --set-upstream-to=origin/2 2 fatal: Cannot setup tracking information; starting point 'origin/2' is not a branch. # THIS WORKS AS EXPECTED: $ git branch --set-upstream-to=origin/1 2 Branch 2 set up to track remote branch 1 from origin by rebasing. -Marc ``` ## Carlos Martín Nieto, 2015-11-23 17:04 Subject: Re: branch --set-upstream-to unexpectedly fails with "starting point ... is no branch" Message-ID: <15ED3D48-282B-44EF-98C6-EA59F18D633E@dwim.me> URL: https://gitlist.dev/e/15ED3D48-282B-44EF-98C6-EA59F18D633E%40dwim.me In-Reply-To: <5652F2D2.3050902@syntevo.com> ``` 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. If you had ‘refs/heads/2:refs/remotes/origin/2’ then it would know, but other remote-tracking branches (e.g. ‘origin/3’) would still have an unknown source. The error message is indeed bogus; it’s likely one of the functions assuming how it’s going to be used. cmn ``` ## Marc Strapetz, 2015-11-23 18:59 Subject: Re: branch --set-upstream-to unexpectedly fails with "starting point ... is no branch" Message-ID: <56536224.3050306@syntevo.com> URL: https://gitlist.dev/e/56536224.3050306%40syntevo.com In-Reply-To: <15ED3D48-282B-44EF-98C6-EA59F18D633E@dwim.me> ``` 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? -Marc ``` ## Carlos Martín Nieto, 2015-11-24 16:58 Subject: Re: branch --set-upstream-to unexpectedly fails with "starting point ... is no branch" Message-ID: <12A15BA3-11C2-426A-87D6-421BA9708A51@dwim.me> URL: https://gitlist.dev/e/12A15BA3-11C2-426A-87D6-421BA9708A51%40dwim.me In-Reply-To: <56536224.3050306@syntevo.com> ``` 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. You can configure the individual refspecs so a ‘git fetch’ call will download the ones you want, giving you the issue you mention here; or you can configure the default refspec, but always pass explicit instructions to git-fetch, like ‘git fetch refs/heads/1 refs/heads/2’. Newer git versions (past 1.9.3 I think) will update the remote-tracking bracnhes when you do it this way. Both of these are annoying in their own way. The second way might be preferable if the fetching is done by a script. But if you absent-mindedly run a lone ‘git fetch’, then you’ll download all branches. Cheers, cmn ``` ## Marc Strapetz, 2015-11-25 16:27 Subject: Re: branch --set-upstream-to unexpectedly fails with "starting point ... is no branch" Message-ID: <5655E186.8060205@syntevo.com> URL: https://gitlist.dev/e/5655E186.8060205%40syntevo.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 ```