I almost lost faith in git's merging capabilities because merge- recursive limits rename detection to the default limit if not configured otherwise. I tried to do a large merge and was pretty convinced that git would handle the merge easily. But it unexpectedly failed to detect the renames. The reason is that merge-recursive uses the diff_rename_limit_default, which is 100, and this was too low in my case. After debugging all the merge and diff machinery I found out that I just need to set diff.renamelimit=0 and everything works smoothly. Well, it was an interesting debugging experience and I learnt a lot about the diffcore. Nonetheless this was one of the worst experiences I had with git and it kept me from doing more important work. I think that limiting rename detection during merge is a really bad idea. Either we should set it to unlimited, or at least we should print a BIG WARNING that rename detection is limited during the merge. I'd propose to override diff.renamelimit to unlimited for a merge, even if diff.renamelimit is explicitly configured by the user. It doesn't make sense not to detect renames during a merge. Opinions? Steffen - 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
