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