Re: [PATCH] log: fix --max-count when used together with -S or -G

[Jeff King <peff@peff.net>]

On Wed, Mar 09, 2011 at 09:52:15PM +0100, Matthieu Moy wrote:

> --max-count is implemented by counting revisions in get_revision(), but
> the -S and -G take effect later (after running diff), hence,
> --max-count=10 -Sfoo meant "examine the 10 first revisions, and out of
> them, show only those changing the occurences of foo", not "show 10
> revisions changing the occurences of foo".
> 
> In case the commit isn't actually shown, cancel the decrement of
> max_count.

Hmm. Is this papering over a bigger problem, which is that we are
throwing out commits at the time of diff rather than finding out early
whether they are TREESAME?

That is, you fixed this:

  git log -100 -Sfoo

but this is still broken:

  git log --parents -Sfoo

in that parent rewriting doesn't happen. You can see the results with
"gitk -Sfoo" (compare to "gitk -- path", which properly shows a
simplified history).

This is also a problem with --follow. Maybe others.

One solution is to hoist the diffcore_std stuff up to rev_compare_tree,
so we get pickaxe and rename-detection at that level. But there may be
some performance implications, especially with respect to saving the
intermediate result to be used by the actual diff generation later on.

So it's definitely a much deeper topic than your small patch. Which
maybe means we should apply your patch now as a band-aid and hope for a
better solution in the long term. I dunno.

-Peff