[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: diff wish

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Wed, 15 Jun 2011 12:24:04 +0100

On Wed, 2011-06-15 at 13:16 +0200, Johan Corveleyn wrote:
> On Wed, Jun 15, 2011 at 12:53 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> > On Wed, Jun 15, 2011 at 12:34:31PM +0200, Branko ─îibej wrote:
> >> I'd say not to worry about --minimal and --nice and whatnot. Just make
> >> diff output the sanest, nicest diff it can find. I think it's a bad idea
> >> to give diff user-visible options that change the output in ways that
> >> are hard to explain (shuffling lines around, as opposed to, e.g., using
> >> a completely different diff format).
> >
> > +1
>
> Certainly we need to pick the best possible default, which satisfies
> most users most of the time.
>
> But I'm not convinced that we should simply drop support for "minimal
> diffs" when we arrive at the point that we have a "nice" format. A
> "nice" diff will always be based on heuristics, taking guesses at what
> should be considered a deletion, an addition, or a common line. It's a
> matter of interpretation. So there will always be a chance that it
> guesses wrong, and totally mis-synchronizes. It may be rare, but IMHO
> it's impossible to completely avoid this.
>
> The minimal diff can produce ugly diffs, but there is one certainty:
> it's always a minimal one.

But so what? It's only "minimal" according to the current definition of
"minimal" which is something like "number of lines removed + number of
lines added". A "better" solution might have a "better" definition of
"minimal", maybe involving something like "total number of unique groups
of characters".

- Julian

> I think that we always need to have that
> around, even if only as a fallback option (just another one of the
> '-x' options) just in case the nice diff gets it wrong. Just like GNU
> diff still has the --minimal option.
>
Received on 2011-06-15 13:24:42 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.