On Thu, Jun 18, 2015 at 11:08:16AM -0700, Junio C Hamano wrote: > So as I said, I do not think it would hurt to have this as an > incremental improvement (albeit going in a possibly wrong > direction). > > Of course, it is a separate question if this change makes the output > worse, by comparing unmatched early parts of two hunks and making > nonsense highlight by calling highlight_pair() more often. As long > as that is not an issue, I am not opposed to this change, which was > what I meant to say by "this might not hurt". Yes, that is my big concern, and why I punted on mismatched-size hunks in the first place. Now that we have a patch, it is easy enough to "git log -p | diff-highlight" with the old and new versions to compare the results. It certainly does improve some cases. E.g.: -foo +foo && +bar in a test script becomes more clear. But some of the output is not so great. For instance, the very commit under discussion has a confusing and useless highlight. Or take a documentation patch like 5c31acfb, where I find the highlights actively distracting. We are saved a little by the "if the whole line is different, do not highlight at all" behavior of 097128d1bc. So I dunno. IMHO this does more harm than good, and I would not want to use it myself. But it is somewhat a matter of taste; I am not opposed to making it a configurable option. -Peff -- 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