Re: [RFC/PATCH 0/2] Color moved code differently

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 4, 2016, 22:19 UTC
Message-ID: <xmqq60qbqpdd.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqqpookqi8k.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 26 quoted lines

> I do not think you should step outside diff_flush().  Only when
> producing textual diff, you would have to run the textual diff
> twice by going over the q twice:
>
>  * The first pass would run diff_flush_patch(), which would call
>    into xdiff the usual way, but the callback from xdiff would
>    capture the removed lines and the added lines without making any
>    output.
>
>  * The second pass would run diff_flush_patch(), but the callback
>    from xdiff would be called with additional information, namely,
>    the removed and the added lines captured in the first pass.
> ...
>    The fn_out_consume() function working in the "second pass of
>    moved from/moved to mode" would inspect line[] and see if it is
>    an added or a removed line, and then:
>
>    - if it is an added line, and it appears as a removed line
>      elsewhere in the patchset (you obtained the information in the
>      first pass), you show it as "this was moved from elsewhere".
>
>    - if it is a removed line, and it appears as an added line
>      elsewhere in the patchset (you obtained the information in the
>      first pass), you show it as "this was moved to elsewhere".
>
> Or something like that.

Actually, the first pass above ends up queuing majority of the diff output in-core _anyway_, so it would make much more sense not to rely on the reproducibility of xdiff machinery by not calling it twice. Instead, I would imagine that the first pass can queue all what it receives in the callback, then with the whole-patch picture at hand, you can call updated fn_out_consume() yourself (instead of letting xdiff machinery to call you), and that would become the "second pass".