Re: branch --set-upstream-to unexpectedly fails with "starting point ... is no branch"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Mark,

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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]