On Sat, Mar 31 2012, da...@tethera.net wrote: > From: David Bremner <brem...@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 _______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch