Thomas Rast <trast@xxxxxxxxxxxxxxx> writes: > 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html