Hacker News Reader

Comment by myhf | Hacker News Reader

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...

View on HN

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

Same, I basically take the derivative of a bug wrt every major dimension before I fix it.

> 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?

I see it all the time, it is fixing the symptoms usually. It kind of works until it doesn’t and it fails miserably.

So yes you can and it works, sometimes…

You can "fix" it (make the current reproducer not reproduce it anymore).

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

Reply on news.ycombinator.com