Johan Corveleyn wrote:
> On Wed, Jun 15, 2011 at 1:24 PM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> > 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:
> >> But I'm not convinced that we should simply drop support for "minimal
> >> diffs" [...]
> >>
> >> 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" [...]
My point was meant to be: GNU diff is intended to be a general and
complete "diff" utility, and so it makes sense for it to implement all
options that might be useful in any usage, for research purposes, for
readability in typical cases, for balancing speed against quality, etc.
But Subversion's built-in "diff" does not need to be complete and
general because users always have the option of plugging in another diff
that suits their needs better. It is intended to give users a
convenient way to see what they've changed (in "text" files), and to
communicate such changes in the form of a patch, and that's *all* it
needs to do.
> The current implementation is "minimal" according to the *most
> natural* definition of "minimal" for diff output, which is still line
> based.
Logically simple, yes. Venerable, yes. Natural, in the sense of "makes
most sense to humans"? No. It totally disregards the content of a
line, which humans don't.
> Ok, you can have another definition of "minimal", but it will
> always have its vulnerabilities in certain cases. That's mainly my
> point.
I totally agree with you there, that any definition will have some kind
of "vulnerabilities", except that's perhaps too strong a word. I didn't
read that as being mainly your point.
- Julian
Received on 2011-06-15 14:56:33 CEST