Bug in git log -S

Bug in git log -S

[Sam Clymer]

There is a bug in git log -S where it doesn’t find every instance of the search string. I am working at Microsoft on internal code so I’m not sure if I’m allowed to share a repro.

Many thanks,
Sam Clymer

Re: Bug in git log -S

[Johannes Sixt]

Am 13.05.24 um 03:40 schrieb Sam Clymer:
> There is a bug in git log -S where it doesn’t find every instance of
> the search string.
-S does not search for *every* instance of the search string, but only
for those that change the number of occurrences of the search string in
the repository.

For example, if you have a commit that only moves a line of code around
that contains the search string, i.e., it removes the search string in
one place and adds it in another places, this commit will not be listed,
because it does not change the number of times that the search string
occurs in the repository.

There is also -G. Maybe it is what you are looking for?

-- Hannes

Re: Bug in git log -S

[Sam Clymer]

There does seem to be a bug on my end. I am searching for “net8.0-windows” and it’s not finding an instance where it’s added. It is not a line of code that is moved around it is purely added so I think there is indeed something wrong with git log -S.

Please let me know if I can be of help in resolving this.

Many thanks,
Sam Clymer

> On May 13, 2024, at 1:55 AM, Johannes Sixt <j6t@kdbg.org> wrote:
> 
> Am 13.05.24 um 03:40 schrieb Sam Clymer:
>> There is a bug in git log -S where it doesn’t find every instance of
>> the search string.
> -S does not search for *every* instance of the search string, but only
> for those that change the number of occurrences of the search string in
> the repository.
> 
> For example, if you have a commit that only moves a line of code around
> that contains the search string, i.e., it removes the search string in
> one place and adds it in another places, this commit will not be listed,
> because it does not change the number of times that the search string
> occurs in the repository.
> 
> There is also -G. Maybe it is what you are looking for?
> 
> -- Hannes
> 

Re: Bug in git log -S

[Johannes Sixt]

Am 13.05.24 um 20:58 schrieb Sam Clymer:
> There does seem to be a bug on my end. I am searching for
> “net8.0-windows” and it’s not finding an instance where it’s added.
> It is not a line of code that is moved around it is purely added so I
> think there is indeed something wrong with git log -S.

You would have to show more evidence for a bug before anything can
happen. Start with showing the commands typed and their output, ideally
you point at a commit history that shows the problem, etc. Otherwise, we
can only say: "it works here".

-- Hannes

Re: Bug in git log -S

[Jeff King]

On Mon, May 13, 2024 at 11:01:25PM +0200, Johannes Sixt wrote:

> Am 13.05.24 um 20:58 schrieb Sam Clymer:
> > There does seem to be a bug on my end. I am searching for
> > “net8.0-windows” and it’s not finding an instance where it’s added.
> > It is not a line of code that is moved around it is purely added so I
> > think there is indeed something wrong with git log -S.
> 
> You would have to show more evidence for a bug before anything can
> happen. Start with showing the commands typed and their output, ideally
> you point at a commit history that shows the problem, etc. Otherwise, we
> can only say: "it works here".

I agree that we do not have much to go on here, but here are some
possible lines of enquiry:

  - if we have a specific commit that we expect "-S" to find, what does
    that commit look like? Is it a merge commit? If so, then maybe "-m"
    or "-c" would help? By default I don't think "log -S" will diff
    merges at all. "-m" will diff against both parents (so it is more
    likely to find introductions/deletions, but may show diffs against
    both parents). "-c" should I think mostly show just places where the
    content was introduced by the merge itself, though I haven't thought
    very hard on whether there are weird corner cases.

  - if there's a non-merge commit that we expect to find it in, then
    maybe checking:

      git cat-file blob $commit:$file | grep -Fc net8.0-windows
      git cat-file blob $commit^:$file | grep -Fc net8.0-windows

    would verify that the counts before/after that commit have changed?
    Note that "-F" is important, because -S is by default a string
    match, not a regex. And if the suspected file is binary, then the
    results may depend on your version of grep (GNU grep will correctly
    report the count for items in a binary file).

-Peff