Re: [PATCH 2/2] git-merge-recursive-{ours,theirs}

> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.