On Sun, May 19, 2013 at 6:51 AM, Ramkumar Ramachandra
<artagnon@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html