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
replyThen 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.
replynot 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> the operator would have to be more interested in understanding the root cause than in fixing the current form of the bug...
replyCan 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.
replySo yes you can and it works, sometimes…
You can "fix" it (make the current reproducer not reproduce it anymore).
reply