logoalt Hacker News

myhf • yesterday at 7:06 PM • 3 replies • view on HN

In theory, an agent could use git-bisect to identify when a bug was introduced. But the operator would have to be more interested in understanding the root cause than in fixing the current form of the bug...


Replies

wongarsu • yesterday at 7:40 PM

For me, Claude regularly looks at git blame after identifying a bug, then reads the commit message and other changes in the commit to understand the context of why that behavior was introduced like that. I wouldn't be surprised if it pulled out a git bisect

Then again, my standard instruction is something like "{bug description}. Find the root cause and propose possible solutions" so I guess I fit your profile

➕ show 1 reply
jcelerier • yesterday at 10:42 PM

not really an option when you're working on a large codebase where a bisect means that a lot of steps could be multiple-hours of compiles. E.g if on a simple 12-step bisect you get 6/8 with a full rebuild you've already spent an entire work day on this

caaqil • yesterday at 7:27 PM

> the operator would have to be more interested in understanding the root cause than in fixing the current form of the bug...

Can you even do the latter without the former?

➕ show 2 replies