3 ms·

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 a

by n4r9 3y ago

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.

yjftsjthsd-h 3y ago
I don't know about branches, but if you're just traversing history that's a textbook use for git bisect, right?
- globular-toast 3y ago
  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.
  - amboar 3y ago
    A handy trick I've developed is using`git bisect` to solve otherwise intractable rebase conflicts: https://codeconstruct.com.au/docs/bisect-intractable-rebase-conflicts/ https://codeconstruct.com.au/docs/bisect-intractable-rebase-...
    - eru 3y ago
      You might want to combine this with enabling rerere.
      - amboar 3y ago
        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.
- n4r9 3y ago
  Yes, failure to rtfa on my part.
nonethewiser 3y ago
Thats called git bisect
shinycode 3y ago
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
- lucasoshiro 3y ago
  Probably they use libgit2 instead of git. But you can use git log -L for that.

by n4r9 3y ago

yjftsjthsd-h 3y ago

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

globular-toast 3y ago
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.
- amboar 3y ago
  A handy trick I've developed is using`git bisect` to solve otherwise intractable rebase conflicts: https://codeconstruct.com.au/docs/bisect-intractable-rebase-conflicts/ https://codeconstruct.com.au/docs/bisect-intractable-rebase-...
  - eru 3y ago
    You might want to combine this with enabling rerere.
    - amboar 3y ago
      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.
n4r9 3y ago
Yes, failure to rtfa on my part.

nonethewiser 3y ago

Thats called git bisect

shinycode 3y ago

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

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