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).
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.
