Re: [RFC] New kind of upstream branch: base branch

From: Junio C Hamano <gitster@pobox.com>
Date: May 17, 2013, 19:51 UTC
Message-ID: <7va9ntxu3w.fsf@alter.siamese.dyndns.org>
In-Reply-To: <51968311.1020107@bracey.fi>

Kevin Bracey <kevin@bracey.fi> writes:

Show 8 quoted lines

> On 15/05/2013 23:34, Felipe Contreras wrote:
>>   I think I'm using 'upstream' for something it was not intended to,
>> and
>> I think the current 'upstream' behavior should be split into
>> 'upstream' and 'base'.
>>
> I found myself thinking the same thing. It's really convenient being
> able to set your topic branch's upstream to another local branch, so

What is that "another local branch"?

Is the use case "master forks from origin/master and has its own changes on top, and then topic builds on my master but the range of commits origin/master..topic includes both changes, that is inconvenient to when rebuilding topic on top of my master"?

I'd assume that it is the case, and the answer to the previous question is 'master' in the example.

> git rebase works without parameters. But then I can't use upstream to
> point to a remote version of that topic branch. I want my topic branch
> to know both that it's based on master (or origin/master), and that
> it's upstream is origin/topic.

If we do s/and that it's upstream is/and that it is pushed to/, then I think I am in general agreement (I wrote about it earlier in a separate message).

> So, yes, here's a vote in favour of the general concept.

Yes, you should be able to treat what you build on top (upstream) and where you publish the result (we are still looking for a better name in the other thread) as two distinct things in a triangular workflow. I agree that it is an issue we need to address.

We have solved a half ("push goes to a different repository") but not the other half ("updates a branch whose name is different from the upstream") in the upcoming 1.8.3 release.

The latest round of design from Felipe calls it branch.$name.push, if I am not mistaken.

I think it is somewhat an overkill, though.

It is normal for upstream's name not to match the topic's name (i.e. your 'topic' may branch off of a generic 'master', but would be named after a more specific purpose of the branch and is unlikely to be named 'master'. In other words, branch.$name.merge that points at an upstream that has a name that is totally different from $name is not an exception. So branch.$name.merge that you have to set for each branch is a necessity.

However, if you were to push out 'topic' directly (as opposed to pushing out a result of integrating it and other topic branches to your 'master') to your own publishing point, it is likely you would push it out to the same name (i.e. 'topic' will be pushed out as 'topic', not as 'master'). And if that is your workflow, setting push.default to "current" (and setting remote.pushdefault to your publishing repository) should be a sufficient interim solution, and you do not need to set branch.$name.push to each and every branch you intend to push out, I think.