On Thu, Nov 11, 2010 at 5:41 AM, Thomas Rast <trast@xxxxxxxxxxxxxxx> wrote:
> 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.)
--
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