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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 18, 2011, 21:26 UTC
Message-ID: <7vsjwpkio8.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110118205040.GA20970@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> [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.

Honestly, my guess is that the interaction of -S with a merge commit is "whatever the code happens to do", as I didn't think nor design how they should interact with each other when I wrote -c/--cc nor when I wrote -S. If I recall correctly -S codepath predates -c/--cc by a wide margin, and I wouldn't be surprised at all if pickaxe doesn't work as expected (by anybody's definition of "expectation"), unless you are looking at "-p -m" output, not a combined one.

Having said that, I tend to agree with your latter expectation ("what I want").

By the way, you guys should really not be looking at the disused plumbing-helper -S but instead be advocating its newer and more human friendly cousin -G. 1.7.4 is coming ;-).