Re: Patch text in git-add patch mode lacks whitespace highlighting

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 4, 2020, 18:29 UTC
Message-ID: <xmqqlfpi8au6.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20200203145155.GA272077@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 14 quoted lines

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