Thread (3 messages) flat view 3 messages, 3 authors, 2016-06-15

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

From: Jeff King <hidden>
Date: 2016-06-15 22:50:44

Possibly related (same subject, not in this thread)

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help