On Tue, Feb 04, 2020 at 10:29:53AM -0800, Junio C Hamano wrote:
> Jeff King <peff@xxxxxxxx> writes:
>
> > If just the human-readable one, then many options that change the line
> > count would be problems: diff.context, diff.interhunkcontext,
> > diff.orderfile, etc.
> >
> > If both, then some options would be problematic for applying. Just
> > looking over the list, these jump out at me:
> >
> > - color.diff=always would obviously be an issue (though TBH I think
> > anybody doing that is inviting a lot of breakages anyway)
> >
> > - diff.external would be a problem if it kicked in, though I think it
> > would require --ext-diff to actually do anything
> >
> > - diff.submodule would generate diffs that can't be applied
>
> What can truly help "git add -p" might be a new output mode from
> "git diff", perhaps, in which instead of writing a stream of text
> (with color codes intermixed), the output machinery makes a call to
> API-user supplied callbacks to report ("type of output line", "the
> payload", "list of coloring information") tuples for each line, so
> that the API-user can synthesize _both_ versions it currently uses
> with a single invocation of "diff"? There may be tons of "output
> line" types, like the diff header, hunk header, context, removed,
> added, etc., and depending on the type, the form the payload takes
> may be different (e.g. a context line may be just a plain text, a
> hunk header line may be a five-tuple (pre- and post-context line
> numbers and line countsm plus the function-header line text).
I agree that would be a nice thing to have, and would let us avoid
running the same diff twice. But I don't think it solves the problem you
quoted above, unless all of the features are represented in some
machine-readable form. E.g., what would diff.submodule do in such an
output, and how would "add -p" decide to show it?
> As long as the call the API-user makes to the diff machinery grabs
> everything that is needed for both human and machine consumption in
> a single call, there is no risk of getting confused by two sets of
> inconsistent patch data.
Yes, but we still can't say "use machine-readable output, and turn on
all the config bells and whistles" because we'd have to know how to
handle every bell and whistle.
-Peff
