From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 18 Jan 2011 21:26:15 GMT
Subject: Re: gitk "find commit adding/removing string"/possible pickaxe bug?
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 ;-).