Re: tracking branch for a rebase

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.

quoted

The biggest question is whether it should respect branch.*.merge, or
just branch.*.rebase (I never use the latter simply because I never use
"git pull", but I think it is probably reasonable to restrict it to
cases where you said you are interested in rebasing in general).

Hm, you'll probably want "git merge" to pickup the default as well then,
right? And that should only do so if branch.*.rebase is not set. So
effectively, you still have to use the right command, but can skip the
argument. Having to deal a lot with git-svn, I also regulary use its
"git svn rebase --local", which means "just rebase, don't fetch".

I hadn't considered whether "git merge" should get a default. To be
honest, my intended use case was not really to replace pull, but as a
shorthand for running "git rebase -i". Upstream has the published
commits, so it is a nice shortcut to say "let me munge all of the
commits that I haven't published yet".

Of course the "published" status of those commits is not guaranteed
(they might have been published in another branch, your
tracking refs might not be up to date, etc) but I think it's a good rule
of thumb.

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.

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

-Peff