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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 19, 2012, 10:33 UTC
Message-ID: <7vpq8v1tht.fsf@alter.siamese.dyndns.org>
In-Reply-To: <87wr33wqzl.fsf@thomas.inf.ethz.ch>

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

Show 13 quoted lines

>> Then the revision machinery looks at B.  It does the same between B
>> and A, but this time around, the diff machinery finds that, even
>> though A and B were _not_ TREESAME at the revision traversal level,
>> there is nothing to be shown after filtering with the -w option.
>> Hence no patch is shown and log message for B is not shown, either.
>
> Thanks for the great explanations.
>
> Having spent some time letting this sink in (and being busy doing other
> things), I think it's actually a good idea.  It forces us to go back and
> change it around so that the diff machinery gets a say _before_ we
> simplify history.  I think this bit will be important for log -L history
> to make sense, and it's a bug waiting to happen for the -w case.

Note that this is not limited to "diff_patch() already filters -w".

If you are running with --diff-filter=A to grab only the additions, for example, you may want the merge simplification to know about this filtering as well.

So it is likely that you would want to hook diffcore_std(), not just diff_flush(), to the TREESAME machinery. Obviously you would want to do this only for the merge commits; there is no point doing this for single strand of pearls where the output phase already knows how to squelch output correctly.