All of lore.kernel.org
 help / color / mirror / Atom feed
* branch --set-upstream-to unexpectedly fails with "starting point ... is no branch"
@ 2015-11-23 11:04 Marc Strapetz
  2015-11-23 17:04 ` Carlos Martín Nieto
  0 siblings, 1 reply; 5+ messages in thread
From: Marc Strapetz @ 2015-11-23 11:04 UTC (permalink / raw)
  To: git

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: branch --set-upstream-to unexpectedly fails with "starting point ... is no branch"
  2015-11-23 11:04 branch --set-upstream-to unexpectedly fails with "starting point ... is no branch" Marc Strapetz
@ 2015-11-23 17:04 ` Carlos Martín Nieto
  2015-11-23 18:59   ` Marc Strapetz
  0 siblings, 1 reply; 5+ messages in thread
From: Carlos Martín Nieto @ 2015-11-23 17:04 UTC (permalink / raw)
  To: Marc Strapetz; +Cc: git

Hello Mark,

On 23 Nov 2015, at 12:04, Marc Strapetz <marc.strapetz@syntevo.com> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: branch --set-upstream-to unexpectedly fails with "starting point ... is no branch"
  2015-11-23 17:04 ` Carlos Martín Nieto
@ 2015-11-23 18:59   ` Marc Strapetz
  2015-11-24 16:58     ` Carlos Martín Nieto
  0 siblings, 1 reply; 5+ messages in thread
From: Marc Strapetz @ 2015-11-23 18:59 UTC (permalink / raw)
  To: Carlos Martín Nieto; +Cc: git

On 23.11.2015 18:04, Carlos Martín Nieto wrote:
> Hello Mark,
>
> On 23 Nov 2015, at 12:04, Marc Strapetz <marc.strapetz@syntevo.com> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: branch --set-upstream-to unexpectedly fails with "starting point ... is no branch"
  2015-11-23 18:59   ` Marc Strapetz
@ 2015-11-24 16:58     ` Carlos Martín Nieto
  2015-11-25 16:27       ` Marc Strapetz
  0 siblings, 1 reply; 5+ messages in thread
From: Carlos Martín Nieto @ 2015-11-24 16:58 UTC (permalink / raw)
  To: Marc Strapetz; +Cc: git


On 23 Nov 2015, at 19:59, Marc Strapetz <marc.strapetz@syntevo.com> wrote:

> On 23.11.2015 18:04, Carlos Martín Nieto wrote:
>> Hello Mark,
>> 
>> On 23 Nov 2015, at 12:04, Marc Strapetz <marc.strapetz@syntevo.com> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: branch --set-upstream-to unexpectedly fails with "starting point ... is no branch"
  2015-11-24 16:58     ` Carlos Martín Nieto
@ 2015-11-25 16:27       ` Marc Strapetz
  0 siblings, 0 replies; 5+ messages in thread
From: Marc Strapetz @ 2015-11-25 16:27 UTC (permalink / raw)
  To: Carlos Martín Nieto; +Cc: git

On 24.11.2015 17:58, Carlos Martín Nieto wrote:
>
> On 23 Nov 2015, at 19:59, Marc Strapetz <marc.strapetz@syntevo.com> wrote:
>
>> On 23.11.2015 18:04, Carlos Martín Nieto wrote:
>>> Hello Mark,
>>>
>>> On 23 Nov 2015, at 12:04, Marc Strapetz <marc.strapetz@syntevo.com> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2015-11-25 16:27 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-23 11:04 branch --set-upstream-to unexpectedly fails with "starting point ... is no branch" Marc Strapetz
2015-11-23 17:04 ` Carlos Martín Nieto
2015-11-23 18:59   ` Marc Strapetz
2015-11-24 16:58     ` Carlos Martín Nieto
2015-11-25 16:27       ` Marc Strapetz

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.