Bug in git log -S

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

Am 13.05.24 um 03:40 schrieb Sam Clymer:

-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

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

Am 13.05.24 um 20:58 schrieb Sam Clymer:

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

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

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