On Thu, 1 Jan 2009, Adeodato Simó wrote: > > For me, the cases where I find patience output to be of substantial > higher readability are those involving a rewrite of several consecutive > paragraphs (i.e., lines of code separated by blank lines). Compare: I don't think that's a "patience diff" issue. That's simply an issue of merging consecutive diff fragments together if they are close-by, and that's independent of the actual diff algorithm itself. > I'll note that in this particular case, `git diff` yielded the very same > results with or without --patience. I don't know why that is, Johannes? > I'll also note that /usr/bin/diff produces (in this case) something > closer to patience than to git. See above - I really don't think this has anything to do with "patience vs non-patience". It's more akin to the things we do for our merge conflict markers: if we have two merge conflicts next to each other, with just a couple of lines in between, we coalesce the merge conflicts into one larger one instead. We don't do that for regular diffs - they're always kept minimal (ok, not really minimal, but as close to minimal as the algorithm finds them). See commit f407f14deaa14ebddd0d27238523ced8eca74393 for the git merge conflict merging. We _could_ do similar things for regular diffs. It's sometimes useful, sometimes not. 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
