On Sun, May 19, 2013 at 6:51 AM, Ramkumar Ramachandra
<artag...@gmail.com> wrote:
> Felipe Contreras wrote:
>> % git checkout fc/remote/hg-next
>> % git rebase -i # rebase to master
>> % git checkout fc/remote/hg-notes
>> % git rebase -i # rebase to fc/remote/hg-next
>> % git checkout fc/remote/hg-gitifyhg-compat
>> % git rebase -i # rebase to fc/remote/hg-notes
> So it is rebase, but rebase.defaultUpstream = origin won't suffice.
> You want to specify a custom base.  What I don't understand is why
> you're abusing @{u},

There's no abuse; 'upstream' is meant *exactly* for this: rebase, and pull.

It's called upstream because that's where eventually all the code must
go, so semantically it's *exactly* correct: 'origin/master' is the
upstream of 'master' which is the upstream of 'fc/remote/hg-next',
which is the upstream of 'fc/remote/hg-notes', and so on.

And if I where to merge a branch from 'master', it make sense that the
default is 'origin/master', because that's the upstream.

Literally each and every way in which 'upstream' is used remains the
same for local branches, except for 'git push'.

> and crippling remote (by hard-interpreting it as
> "origin") to achieve this.

More false rhetoric; "origin" is *ALREADY* the default.

Show me the output of these:

%git clone --origin foobar git://git.kernel.org/pub/scm/git/git.git /tmp/git
%cd /tmp/git
%git fetch -v
%git checkout --no-track -b test master
%git fetch -v

> For the record, I didn't think your
> branch.<name>.base was a bad idea at all (re-visiting now).

It makes sens for rebase, but what happens when you do 'git pull' and
you don't have an upstream configured, only a base? Why would you want
'git pull' to fail? In which instances would you want to have a
'base', but not an 'upstream'?

Think about it.

Felipe Contreras
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to