From: "Felipe Contreras" <>
Sent: Wednesday, May 15, 2013 9:34 PM

I've been using Git from the start, but only lately have I forced
myself to configure upstream branches for all my branches, and I've
found a few things more convenient, but others completely contrary to
what I expected.


Before, I used to do 'git fetch' to simply fetch from 'origin', but
now, it depends on where 'upstream' is set to.


Now, I can just do 'git rebase --interactive' and I don't have to
specify the starting point, which is particularily useful when there's
a lot of branches one depending on another.

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

== base ==

The 'base' branch will be set each time you create a branch from another; 'git checkout -b foobar master' sets 'master' as the 'base' of 'foobar'.

Then you can do 'git rebase foobar@{base}' or simply 'git rebase', and
Git will pick the right branch to rebase unto, even if you have no

This way 'git fetch' will keep picking 'origin', and other commands
that make use of 'upstream' would be undisturbed.

If both 'base' and 'upstream' are defined, I think 'git rebase' should
use 'base', but since that would break old behavior, perhaps there
should be a configuration variable to enable a different behavior.

I already started writting the patches, and although tedious, I think
they they'll be rather straightforward, but I thought it would be best
to hear some opinions first.

What do you think?

Felipe Contreras
Sound a reasonable idea. On some patches I was working on I had to [chose to] add a tag for the base which made it easier to rebase later.

The other point is that I had already noted that the glossary doesn't include the many "base" terms in use that aren't always well understood.

Philip Oakley
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to