Re: [PATCH v2] rebase -X: do not clobber strategy

On Thu, Nov 11, 2010 at 5:41 AM, Thomas Rast [off-list ref] wrote:

Martin von Zweigbergk wrote:

quoted

Btw, why is the default (if no strategy is specifed) for 'git rebase' to
use 'recursive', while for 'git merge' "a built-in list of strategies is
used instead (git merge-recursive when merging a single head, git
merge-octopus otherwise)"?

Because rebase does a tree-level merge, so it never attempts to merge
than one branch, so octopus never enters the picture.

I can see why octopus doesn't make sense when doing a linearizing
rebase, but what if it's merge-preserving rebase? The call to
'git merge' in git-rebase--interactive.sh looks like this:
    new_parents=${new_parents# $first_parent}
    [...]
    git merge $strategy -m "$msg" $new_parents

Also, it sounds like "a built-in list" is something that could one day
be expanded. So my question is then whether it would make sense to call
'git merge' without specifying a strategy when 'git rebase' is called
without a strategy?

Sorry for the original breakage; while it has Mike Lundy assigned as
author, I resurrected and resubmitted his patch and should have
noticed.

Well, since there are no other strategies than recursive that support
strategy options, it was not really a breakage in reality, at least as
far as I can see.

Speaking of that and about my earlier comment about writing a test case,
what should really happen if the user calls 'git rebase -s ours -X foo'?
Should it really be allowed? (I tried it and it does work, though.)