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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 17, 2013, 20:15 UTC
Message-ID: <CAMP44s14CtWS=cGsF=ZqYPrCmSPjjc-8XQFZ7gD==Dg8sESRfQ@mail.gmail.com>
In-Reply-To: <7va9ntxu3w.fsf@alter.siamese.dyndns.org>

On Fri, May 17, 2013 at 2:51 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 12 quoted lines

> Kevin Bracey <kevin@bracey.fi> writes:
>
>> 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"?

refs/heads/*

> 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"?

No it's not. You just 'git rebase -i' and everything works.

Show 27 quoted lines

> 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 needed.

Show 13 quoted lines

> 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').

Likely, but not certain.

Show 5 quoted lines

> 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.

If git needs configurations to behave sanely, git is broken.

If we set: branch.autosetupmerge = always push.default = simple

By default in v2.0, and there's a UI to set remote.pushdefault, then I might be inclined to agree that branch.$name.push is overkill.

But I don't see that happening; the user still needs a sane way to make trivial workflows work without hacking the configuration.

-- 
Felipe Contreras