Re: gitk "find commit adding/removing string"/possible pickaxe bug?

From: Jeff King <peff@peff.net>
Date: Jan 18, 2011, 20:50 UTC
Message-ID: <20110118205040.GA20970@sigill.intra.peff.net>
In-Reply-To: <201101182139.28808.trast@student.ethz.ch>

On Tue, Jan 18, 2011 at 09:39:28PM +0100, Thomas Rast wrote:

Show 14 quoted lines

> So indeed
> 
>   git log -Squux -c -p
> 
> gives a combined diff.  But OTOH
> 
>   git log -Sbar -c -p
> 
> doesn't; it only gives a diff for the commit that introduced 'bar'.  I
> guess this makes sense: -S notices that the number of 'bar's is
> actually the same as in *one* merge parent, hence the merge cannot be
> all that interesting.  OTOH it still shows the merge commit in the
> history, which is a bit strange.  --pickaxe-all does not make a
> difference either;

Hrm. What I expected[1] to happen would be for the diff machinery to look at each filepair individually, one of them to trigger -S, which shows the commit, and then to fail to produce a combined diff because we threw away the other uninteresting filepair. But in that case, --pickaxe-all _should_ show something, as its point is to keep all of the filepairs. And that's clearly not happening.

So now I don't know what's going on. I'll try to trace through the diff machinery and see if that gives a clue.

-Peff

[1] That's what I expect, but not necessarily what I want. I think what I would want is for it to do a token count of the merge commit, and if it fails to match _every_ parent, then it it interesting. Otherwise, the content presumably came from that parent.