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

Kevin Bracey [off-list ref] writes:

quoted

quoted

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

quoted

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

Do you mean, by "save typing", "instead of origin/master, I can type
master"?

If you are using the "checkout -t -b topic origin/master", "git rebase"
without any other argument should know that you meant to rebase
against 'origin/master', so you do not even have to type '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.

Yup, that is sensible, and I think with Felipe's proposed change,
you can spell it like this:

    [branch "topic"]
	remote = origin
	merge = refs/heads/master
        push = refs/heads/kbracey/topic

Note that the above assumes you did "checkout -t -b topic origin/master"
as a typesaver for "git rebase".

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

Understood.  And I think the [branch "topic"] configuration above
would cover that use case.

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

"git pull --rebase" would be "git fetch" followed by "git rebase",
and again the [branch "topic"] configuration above would cover that
use case, I think.

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

I think checkout and branch is already covered with -t.  There may
even be a configuration option to implicitly add -t to them (I
didn't check).

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

Yeah, I would imagine that it would be trivial to add an option to
cause "git push" to do that, and it would be useful if you push to
and pull from the same place (I haven't thought about ramifications
such an option would have on the triangular workflows, though).

Thanks.

Junio C Hamano wrote:

Kevin Bracey [off-list ref] writes:

quoted

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

I think checkout and branch is already covered with -t.  There may
even be a configuration option to implicitly add -t to them (I
didn't check).

branch.autosetupmerge=always

quoted

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

Yeah, I would imagine that it would be trivial to add an option to
cause "git push" to do that, and it would be useful if you push to
and pull from the same place (I haven't thought about ramifications
such an option would have on the triangular workflows, though).

It would work wonderfully. Now:

== remote ==

% git checkout -b master origin/master
# work
% git push

== local ==

% git checkout -b topic master
# work
% git push # ERR
% git push -u origin/master
# work
% git push # ERR

That doesn't work. We could set branch.autosetupmerge=always as the default,
but it still wouldn't work, because push.default=simple (or at least it will
be), and the names don't match.

But with my patches, and branch.autosetupmerge=always (hopefully for 2.0):

== local ==

% git checkout -b topic master
# work
% git push # ERR
% git push --set-downstream origin/master
# work
% git push

Cheers.

-- 
Felipe Contreras