Kevin Bracey <kevin@xxxxxxxxx> 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"?
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.
--
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