Hi,
On Sat, 21 Jun 2008, Junio C Hamano wrote:
> 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".
Fair enough.
> 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.
Looks fine to me. And much cleaner than the hardlinking.
Ciao,
Dscho
--
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
