Re: [PATCH] Re: Clarify documentation on the "ours" merge strategy.

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