From: Jonathan del Strother <jdelstrother@gmail.com>
Date: Thu, 23 Dec 2010 17:27:39 GMT
Subject: Re: Expected behaviour of 'git log -S' when searching in a merged/deleted file?
Message-ID: <AANLkTinS6i0K4MMdr_E94ig-V3oMFZ+L7N=mqn0S3Y7T@mail.gmail.com>
In-Reply-To: <7vwrn0328p.fsf@alter.siamese.dyndns.org>

On 23 December 2010 16:03, Junio C Hamano <gitster@pobox.com> wrote:
> Jonathan del Strother <jdelstrother@gmail.com> writes:
>
>> ....  If 'needle' was added
>> and removed within the duration of a single branch, I could understand
>> "git log -S" never finding 'needle' due to history simplication, but I
>> don't understand how simplification applies here.
>
> Ahh, sorry, I misunderstood the scenario.  Just like you do not see a
> patch output from "log -p", the diff machinery (including -S and its newer
> cousin -G) does not kick in by default for merge commits (this is a bit of
> white lie as "log -p" defaults to "combine diff", i.e. be silent on any
> uninteresting merge that takes its results literally from either parent).
>
> Please try it with "-m" (not "--full-history").  We _might_ want to change
> this behaviour for -S/-G but it needs a bit more thought.
>

Yep, '-m' produces the expected (or at least, *my* expected) results.