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
