On Wed, Jun 20, 2012 at 11:44:25AM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > Fine by me. I think "xdiff_found_changes" is not quite accurate; it is > > really "did builtin_diff find any changes?" since we might never call > > into xdiff (e.g., for binary files). I'm not sure what the best name is. > > "diffopt.found_changes" is clear enough for me. I thought this bug would be enough to show that diffopt.found_changes is not clear enough. It is the source of the original bug (the code should have been using HAS_CHANGES instead of found_changes), and it gave at least one of the bug investigators (i.e., me) quite a bit of confusion to understand why found_changes was not being set when diff_flush found changes. IOW, as a naive reader of the "struct diff_options", how do I understand the difference between HAS_CHANGES and found_changes? -Peff -- 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