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

From: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Date: Nov 11, 2010, 12:59 UTC
Message-ID: <AANLkTinBhDR2+SGtz4rmj8CrOh4yLPAB3A74BV-yBCxa@mail.gmail.com>
In-Reply-To: <201011111141.33623.trast@student.ethz.ch>

On Thu, Nov 11, 2010 at 5:41 AM, Thomas Rast <trast@student.ethz.ch> wrote:

Show 8 quoted lines

> Martin von Zweigbergk wrote:
>> 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.)