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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jan 2, 2009, 01:56 UTC
Message-ID: <alpine.LFD.2.00.0901011747010.5086@localhost.localdomain>
In-Reply-To: <20090101204652.GA26128@chistera.yi.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