Re: tracking branch for a rebase

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2009.09.05 02:12:50 -0400, Jeff King wrote:
> On Fri, Sep 04, 2009 at 08:59:49PM +0200, Björn Steinbrink wrote:
> 
> > "git pull --rebase" is not the same as:
> > "git fetch origin && git rebase origin/foo", but:
> > 
> > git fetch origin && git rebase --onto origin/foo $reflog_merge_base
> > 
> > Where $reflog_merge_base is the first merge base is found between the
> > current branch head, and the reflog entries for origin/foo.
> 
> Thanks, I didn't know about the trick (not being, as I mentioned, a pull
> --rebase user). I can see arguments for or against a rebase-default
> using that feature. On one hand, it simplifies the explanation for
> people going between "pull --rebase" and "fetch && rebase". And I think
> it should generally Do What You Mean in the case that upstream hasn't
> rebased. Are there cases you know of where it will do the wrong thing?
> 
> I don't know if people would be confused that "git rebase" does not
> exactly default to "git rebase $upstream", which is at least easy to
> explain.

For me, the confusion would arise from the fact that "git rebase"
(without args) would seem like a "pull --rebase" without the fetch, but
isn't. And to reducing the difference to just the fetch would require a
quite change in bahaviour.

Currently, when branch.<name>.merge is set:
"git rebase <upstream>" ==> Can't really be done with "pull --rebase"
"git pull --rebase [...]" ==> Can't be done with "rebase" alone.

Currently, "pull" is a convenience thing, and thus may do more magic,
while "rebase" is dumb, and needs arguments. Starting to add _different_
magic to rebase seems wrong to me.

> And by automating the shorthand we reduce the chance of errors. For
> example, I usually base my topic branches from origin/master. But the
> other day I happened to be building a new branch, jk/date, off of
> lt/approxidate, salvaged from origin/pu. I did "git rebase -i
> origin/master" and accidentally rewrote the early part of
> lt/approxidate.

Hm, I'd prefer a shorthand for "upstream for this branch", instead of
magic defaults.

> > Now, basically "git svn rebase" is pretty much git-svn's "pull". Maybe
> > its idea could be taken, so we get "git pull --local" to just skip the
> > fetch part, but keep "git rebase" and "git merge" 'dumb', requiring
> > explicit arguments.
> 
> That wouldn't help me, because you can't "pull -i". :)

I probably shouldn't tell anyone, as it's a crude hack, but "git pull
--rebase -s -i" does the trick... *hides*

Björn