Git bisect is never unnecessary. Even when you can easily test the components and find the bug that way, a bisect allows you to understand why the bug was introduced. This is wonderful in all places where there is a culture of writing long and comprehensive commit messages. You get to understand why the bug occurred from a previous commit message and you will write about that context in your bug fix commit message. And this becomes positive reinforcement. The better the commit messages are, the more useful it is to use git bisect or git blame to find the relevant commit messages.

▲

kemayo 4 days ago | parent [-]

Yeah, bisect is really handy because often a bug will have been introduced as a side-effect of a change made to support something else, and if you don't know what new usage was introduced you're relatively likely to break that in the course of fixing the bug.

You can avoid it via the "just look at every usage of this function and hold the entire codebase in your head" method, of course, but looking at the commit seems a bit simpler.

▲

_alternator_ 4 days ago | parent [-]

‘git blame’ is often more handy for finding the reason that the change was made, assuming you know the location of the bug. It tells you the commit and the commit message.

▲

geon 4 days ago | parent | next [-]

Blame doesn’t help when the same code has been changed multiple times since the bug was introduced.

▲

carlmr 4 days ago | parent [-]

While true, this is one reason I always introduce automated code-formatting early on. It makes git blame a bit more useful.

▲

chrismorgan 3 days ago | parent [-]

Automated code formatting, in my experience, never decreases diff sizes, and frequently increases them. Some of those diff size increases support git-blame, some of them hinder it. Around the boundary between two possible formattings, they’re terrible.

Code formatters do tend to force some patterns that may make the line-oriented git-blame more useful such as splitting function calls into many lines, with a single argument on each line; yet that’s not about the code formatter, just the convention. (And the automatic formatters choose it because they have no taste, which is necessary to make other styles consistently good. If you have taste, you can do better than that style, sometimes far better.)

	▲	carlmr 3 days ago \| parent [-]
		Depends on the language and the available formatters really, I find the black/ruff formatting style in Python to be very consistent, which helps with git blame. For C++ there's no good default formatter for "small diffs" since they all, as you say, add random line breaks dependending on position of parameters and such. With style you can do better, but having style is impossible in anything except single developer projects.

▲

kemayo 4 days ago | parent | prev [-]

> assuming you know the location of the bug

Well, yes. But `git bisect` is often the quickest way to find that, in a complex system.