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