Patrick Palka <patr...@parcs.ath.cx> writes: >> I have this nagging feeling that it is just as likely that two >> uneven hunks align at the top as they align at the bottom, so while >> this might not hurt it may not be the right approach for a better >> solution, in the sense that when somebody really wants to do a >> better solution, this change and the original code may need to be >> ripped out and redone from scratch. > > Hmm, maybe. I stuck with assuming hunks are top-aligned because it > required less code to implement :)
Yeah, I understand that. If we will need to rip out only this change but keep the original in order to implement a future better solution, then we might be better off not having this change (if we anticipate such a better solution to come reasonably soon), because it would make it more work for the final improved solution. But if we need to rip out the original as well as this change while we do so, then having this patch would not make it more work, either. 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". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
