Re: [PATCH 0/3] Teach Git about the patience diff algorithm

[Linus Torvalds <torvalds@linux-foundation.org>]

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