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

Thomas Rast [off-list ref] writes:

quoted

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.