On 2009.11.11 23:55:09 -0800, Junio C Hamano wrote: > 58634db (rebase: Allow merge strategies to be used when rebasing, > 2006-06-21) added "-m" and "-s" to rebase to solve the problem of rebasing > against an upstream that has moved files. What the commit actually did > was to use recursive (by default) while giving longer rope to the users by > choosing other strategies with "-s", without making any judgement as to > why other strategies may possibly be useful. At least the original reason for 58634db became (partially?) moot half a year later, thanks to 579c9bb19 "Use merge-recursive in git-am -3". Rebase already falls back to recursive merging in am, so using rebase -m with the recursive strategy just stops it from trying the fast path, right? That should probably be reflected in the man page, but honestly I have no idea what to write there now. The note about recursive should go, but keeping only "Use merging strategies to rebase" doesn't actually look like it's going to be helpful in any way. > Perhaps there is some different issue at the root of this one. Why would > anybody be tempted to say "-s ours" while running a rebase? What did the > user want to see it do (instead of being a no-op because "ours" by > definition ignores the tree the change is replayed from)? Given the few requests I've seen of it (here + #git), I'd guess that the user wants "git rebase -s ours $up" to do either: MB=$(git merge-base $up HEAD) git filter-branch --parent-filter "sed -e s/$MB/$up/" -- HEAD --not $up i.e. just re-attach things to upstream, ignoring whatever upstream did (git-svn users seem to want something like that sometimes to be able to dcommit. Dunno if they have some hatred against the other users of their svn repo ;-)) Or the user wants the infamous "resolve conflicts to want I did", often enough without thinking about what that actually means and how it can easily lead to total crap. (Yes, I'm biased...) 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