There's a use case that merge recursive doesn't seem to handle, and I wonder how difficult it would be to add. Say you have a merge between OURS and THEIRS, with common ancestor BASE. Between BASE and THEIRS, a file named header.h has the following changes: # Rename header.h to header_new.h git mv header.h header_new.h # Minor edits to account for the rename such as fixing the # include guard: perl -pi -e 's/HEADER_H_/HEADER_NEW_H_/' header_new.h # Drop a compatibility header.h in place till we can fix all the # files which include header.h cat > header.h <<-__EOF__ #ifndef HEADER_H_ #define HEADER_H_ #include "header_hew.h" #endif // HEADER_H_ __EOF__ git add header.h header_new.h git commit -m 'rename header.h to header_new.h' Meanwhile, between BASE and OURS, a few minor changes are made to header.h. This could be as little as a single line change in the middle of the header.h. Now you merge THEIRS to OURS. Git will just show header.h in conflict. 99% of the time I can do the following: git diff MERGE_BASE... header.h | patch header_new.h git checkout --theirs header.h git add header.h header_new.h But it would seem like this is something merge recursive should be capable of handling on its own. j. -- 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