Hacker News Reader

Comment by n4r9 | Hacker News Reader

Another way to use git to debug - albeit more tedious - is to manually check out branches (using a binary search) until you find the exact change that caused an issue. This is helpful if you have no idea what part of the code is causing a problem, but you know the problem didn't exist a month ago. Performance issues are a good example.

View on HN

I don't know about branches, but if you're just traversing history that's a textbook use for git bisect, right?

Yep. Git bisect automatically does a binary search to find the earliest breaking commit. You can either test each version manually or, if you have a script that will pass or fail, like a unit test, you can tell git and it will do everything automatically. I love it when I get to use git bisect.

A handy trick I've developed is using`git bisect` to solve otherwise intractable rebase conflicts:

https://codeconstruct.com.au/docs/bisect-intractable-rebase-...

You might want to combine this with enabling rerere.

Yeah, I have rerere turned on However, it's not directly beneficial for the process outlined. With what I wrote about you only solve a given conflict at the end of a complete bisect run, not at each bisection point inside a run. The bisect/cherry-pick process is only used to determine whether conflicts do or don't happen at a given upstream commit. Usually you will solve a specific conflict only once, regardless of whether rerere is enabled.

Yes, failure to rtfa on my part.

In jetbrain products, you can select any bloc of code and show the git history for this particular bloc. I don’t know exactly which command is behind it but I always thought it would be tedious to do it manually like you described

Probably they use libgit2 instead of git. But you can use git log -L for that.

Thats called git bisect

Reply on news.ycombinator.com