Re: Bug in git log -S
- From
Jeff King <peff@peff.net>
- Date
- May 15, 2024, 06:34 UTC
- Message-ID
- <20240515063400.GD110841@coredump.intra.peff.net>
- In-Reply-To
- <6d7ac19b-fede-4534-aee2-5c0cb20f955e@kdbg.org>
On Mon, May 13, 2024 at 11:01:25PM +0200, Johannes Sixt wrote:
Show 10 quoted lines
> 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