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