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

[Kevin Bracey <kevin@bracey.fi>]

On 17/05/2013 22:51, Junio C Hamano wrote:
> 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"? ...  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.

I agree that using "push.default current" covers some cases - I hadn't 
really considered it - tended to just stick with "upstream". "current" 
nearly does the job, but I will sometimes be wanting different names.

What I'll often be doing is creating a topic branch based on master or 
origin/master. (I would hardly ever be updating master or pushing to 
origin/master myself, so I probably should be just doing origin/master, 
but I tend to create a local master just to save typing on all those 
"git rebase origin/master").

During work, to give others visibility, and the possibility to tinker 
with the topic branch during development (as we don't have full 
inter-site sharing of work areas), I would push the topic branch up to 
the central "origin" server, often with a "kbracey/" prefix, partially 
for namespacing, and partially to indicate it's currently "private" work 
and subject to rebasing.  I guess I could create the topic branch as 
"kbracey/topic" locally, but I'd rather not have to.

So I'd like "git rebase (-i)" to move my topic branch up 
(origin/)master. And I'd like "git push (-f)" to send it to 
"origin/kbracey/topic". And by extension, I suppose "git pull --rebase" 
to update origin/master and rebase. (Although I'm not much of a puller - 
I tend to fetch then rebase manually).

The final releasing procedure for the topic branch would be to hand that 
branch over to an integrator, who would then merge/rebase it into master.

And it would be ideal if the initial base and push tracking information 
could be set up automatically on the first "git checkout -b"/"git 
branch" and "git push". (For one, I've always found it odd that there's 
an asymmetry - if you check out a topic branch from the server to work 
on or use it, you get a local copy with upstream set by default. But if 
you create a topic branch yourself then push it, the upstream isn't set 
by default - you need the -u flag. This seems odd to me, and I've seen 
others confused by this).

Kevin