> *1* If somebody wants to do this, one thing to watch out for is > matching up of broken pairs. If a pair originally broken by > diffcore-break (because they were dissimilar enough according to > the option given to -B flag) are merged into one by > diffcore-rename (because they were similar enough according to > the option given to -M flag), we should _not_ say the resulting > pair is renamed. In general, the threashold for breaking should > be lower than diffcore-rename to merge them for a sane use, so > this might be a non-issue in practice, though. Er... no. You want to be fairly aggressive when doing both things. That is, you want to break aggressively so you can look for a better match elsewhere, but once you've found the best match, you don't want to be shy about accepting it. Pulling numbers out of thin air, say break if 1/3 of a file has changed (66% common), and merge if you have 33% common. Or maybe even less. The point of break then merge is to give you a chance to find the 90% common file that has a new name. I always understood that the reason for having two thresholds is exactly so they can have this relationship, not the opposite one as you suggest. - : 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