Re: [PATCH v7 0/5] git log -L, all new and shiny

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 15, 2012, 04:40 UTC
Message-ID: <7vlijpchm2.fsf@alter.siamese.dyndns.org>
In-Reply-To: <cover.1339063659.git.trast@student.ethz.ch>

Thomas Rast <trast@student.ethz.ch> writes:

Show 6 quoted lines

> I too thought it would never happen -- but then again this is still
> not ready, I'm just trying to give it some exposure.
> ...
> There's also a longer-term wishlist hinted at in the commit message of
> the main patch: the diff machinery currently makes no provisions for
> chaining its various bells and whistles.

I am not convinced that it is "diff machinery makes no provivsions" that is the problem. Isn't it coming from the way the series limits the output line range and reimplements its own output routine?

All the "bells and whistles" like diffstat, word coloring, etc. go through the xdi_diff_outf() interface, so isn't it the matter of limiting lines that this interface calls back the "bells and whistles" callback functions with?

When you enter the diff machinery, you have the path and the line range you are interested in of one side (lets say you are comparing side A and B, and have line range for side A).

If you

 - add a mechanism to pass the "interesting" line range and path
   down to the callchain from xdi_diff_outf() to xdiff_outf();

 - make one of these functions filter out (i.e. not call the
   callback xdiff_emit_consume_fn) hunks that do not overlap with
   the line range you are interested in (I would presume that they
   would be a few new fields in xdemitconf_t structure); and

 - while recording the corresponding line ranges in the other side
   of the hunks that are output,

that would give you

 - output that is limited to the "interesting" input range of side A;

 - the corresponding "interesting" range in the other side of the
   comparison, so that you can update the "interesting" range to
   feed to the next diff that compares side B with something else; and

 - for whatever processing the various "bells and whistles" callers
   already implement, as all their callbacks see are the lines in
   your "interesting" range.

No?  Am I missing something?