On Sat, Mar 31 2012, david@tethera.net wrote:

> From: David Bremner <bremner@debian.org>
>
> The recursive merge strategy does rename detection, which yields false
> positives (and hence spurious merge conflicts) when merging trees of
> empty files.

I attempted to search more info about 'recursive' vs 'resolve' merge
but without much luck. Nothing better comes out than MERGE STRATEGIES
section in git-merge namual page.

IMHO text favoring resolve: "It tries to carefully detect criss-cross
merge ambiguities and is considered generally safe and fast."

& text unfavoring recursive (in this particular case): "Additionally
this can detect and handle merges involving renames."

so LGTM.

Tomi

> ---
>  An unresolved issue (ho ho) is the fact that failed merge operations
>  are still not detected. This needs more thought, but I thought this 
>  patch might save people some pain in the meantime. It isn't very heavily 
>  tested, though.
>
>  contrib/nmbug |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/nmbug b/contrib/nmbug
> index bb0739f..0ed3c29 100755
> --- a/contrib/nmbug
> +++ b/contrib/nmbug
> @@ -302,7 +302,7 @@ sub do_merge {
>  
>    git ( { GIT_WORK_TREE => $tempwork }, 'checkout', '-f', 'HEAD');
>  
> -  git ( { GIT_WORK_TREE => $tempwork }, 'merge', 'FETCH_HEAD');
> +  git ( { GIT_WORK_TREE => $tempwork }, 'merge', '-s', 'resolve', 'FETCH_HEAD');
>  
>    do_checkout ();
>  }
> -- 
> 1.7.9.1
>
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch