Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>> @@ -1379,11 +1401,18 @@ int cmd_merge_recursive(int argc, const char **argv, const char *prefix)
>> struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
>> int index_fd;
>>
>> + merge_recursive_variants = 0;
>> if (argv[0]) {
>> int namelen = strlen(argv[0]);
>> if (8 < namelen &&
>> !strcmp(argv[0] + namelen - 8, "-subtree"))
>> - subtree_merge = 1;
>> + merge_recursive_variants = MERGE_RECURSIVE_SUBTREE;
>> + else if (5 < namelen &&
>> + !strcmp(argv[0] + namelen - 5, "-ours"))
>> + merge_recursive_variants = MERGE_RECURSIVE_OURS;
>> + else if (7 < namelen &&
>> + !strcmp(argv[0] + namelen - 7, "-theirs"))
>> + merge_recursive_variants = MERGE_RECURSIVE_THEIRS;
>
> This just cries out loud for a new function suffixcmp().
Actually, I think "git-merge-recursive-theirs" is a mistake. We should
bite the bullet and give "git-merge" an ability to pass backend specific
parameters to "git-merge-recursive". The new convention could be that
anything that begins with -X is passed to the backend.
E.g.
git merge -Xfavor=theirs foo
git merge -Xsubtree=/=gitk-git paulus
As you noticed already, subtree is just a funny optional behaviour
attached to recursive, so are theirs and ours. The above two would invoke
git-merge-recursive like so:
git merge-recursive -Xfavor=theirs <base> -- HEAD MERGE_HEAD
git merge-recursive -Xsubtree=/=gitk-git <base> -- HEAD MERGE_HEAD
We could even mix these two if we are ambitious.
--
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
