Ah, in that case the JetBrains diff tool lets you annotate inside the diff window and I can usually walk back to where this possible off by one error was first authored that way.

It probably would be slightly faster to jump to bisect. But it’s not in my muscle memory.

▲

adastra22 4 days ago | parent [-]

I'm not sure what you mean by "annotate inside the diff window"?

If you mean see what commit added code, that's what git-blame is for.

Bisect is for when you don't know which code, just the behavior.

▲

hinkley 4 days ago | parent [-]

Git blame doesn’t show you why line 22 has a bug in it. It only shows you who touched it last. And that’s if nobody fucked up a merge.

A single line of code can have half a dozen authors. You have to pick back through the history and keep running git blame until you determine who put the bug in that line, and why.

If you show the side by side diff for a commit in JetBrains, you can click show annotations and it’ll show you the blame for the before. And then you can keep going back. For a large file that saves you having to go through all the other commits that were done in completely other parts of the file. Which can be a lot for large files.

	▲	adastra22 4 days ago \| parent [-]
		That sounds more complicated than git bisect. When I bisect I have a short test script that confirms the bug. Usually, I already have this because part of the bug report/identification. I then run "git bisect run path/to/bug.sh". That's it -- it will output which commit caused the change. Those occasional times I need to confirm the presence of actual text, I use sh -c "git grep ..." as the test command.