On Fri, 2 Jan 2009, Johannes Schindelin wrote: > > FWIW it's the test case in the commit introducing the --patience option. Well, it's also the test-case in the very first hit on google for "patience diff" (with the quotes). In fact, it's the _only_ one I ever found ;) > And the worst part: one can only _guess_ what motivated patience diff. I > imagine it came from the observation that function headers are unique, and > that you usually want to preserve as much context around them. Well, I do like the notion of giving more weight to unique lines - I think it makes sense. That said, I suspect it would make almost as much sense to give more weight simply to _longer_ lines, and I suspect the standard Myers' algorithm could possibly be simply extended to take line size into account when calculating the weights. Because the problem with diffs for C doesn't really tend to be as much about non-unique lines as about just _trivial_ lines that are mostly empty or contain just braces etc. Those are quite arguably almost totally worthless for equality testing. And btw, don't get me wrong - I don't think there is anything wrong with the patience diff. I think it's a worthy thing to try, and I'm not at all arguing against it. However, I do think that the people arguing for it often do so based on less-than-very-logical arguments, and it's entirely possible that other approaches are better (eg the "weight by size" thing rather than "weight by uniqueness"). The thing about unique lines is that there are no guarantees at all that they even exist, so a uniqueness-based thing will always have to fall back on anything else. That, to me, implies that the whole notion is somewhat mis-designed: it's clearly not a generic concept. (In contrast, taking the length of the matching lines into account would not have that kind of bad special case) Linus -- 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
