On Wed, 2011-06-15 at 13:16 +0200, Johan Corveleyn wrote: > On Wed, Jun 15, 2011 at 12:53 PM, Stefan Sperling <s...@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. >
