3 ms·

git bisect imo relies on having good commit discipline to be as useful as possible, so many novice git users will not find it useful (identifying the bad commit

git bisect imo relies on having good commit discipline to be as useful as possible, so many novice git users will not find it useful (identifying the bad commit among "fix thing" "add stuff" "aasdfasdfljser", all of which are +1000/-1000, is not going to help with much).

withinboredom 4y ago
So much this. Especially if you are squashing PRs, this tool is barely useful. I once tried to bisect the problem and I was able to narrow down the PR that introduced the bug, but the PR was made up of hundreds of commits squashed into one. So, we knew what PR it happened in, and it wasn't surprising because the PR touched dozens of files and hundreds, if not thousands of lines. The PR was a landing PR, in that people opened PRs into a staging branch and then eventually merged that one into the mainline. If the commits weren't squashed, we could have narrowed down to the individual commit that introduced the (revenue affecting) bug and probably fixed the issue relatively quickly. IIRC, any git-bisect shouldn't take more than ~12ish attempts to find the breaking commit, no matter how many commits there are. At least we knew which PR the issue was affected by, but instead of just hot-fixing what was probably a one-liner, we had to either revert the entire new feature or read through all the changes to find the issue.
- account42 4y ago
  This is exactly why so many of us a vehemently opposed to squashing. But in case you still have the original refs for the PR you can run bisect on that to narrow it down - assuming that the individual commits are (somewhat) consistent states that can be built.
- ddevault 4y ago
  Squashing isn't the problem. What you should be doing is trying to make each commit the smallest possible atomic unit of change. Rebase is a useful tool for achieving this -- squashing, splitting, whatever. git add/commit -p also good for this.

withinboredom 4y ago

So much this. Especially if you are squashing PRs, this tool is barely useful. I once tried to bisect the problem and I was able to narrow down the PR that introduced the bug, but the PR was made up of hundreds of commits squashed into one. So, we knew what PR it happened in, and it wasn't surprising because the PR touched dozens of files and hundreds, if not thousands of lines. The PR was a landing PR, in that people opened PRs into a staging branch and then eventually merged that one into the mainline. If the commits weren't squashed, we could have narrowed down to the individual commit that introduced the (revenue affecting) bug and probably fixed the issue relatively quickly. IIRC, any git-bisect shouldn't take more than ~12ish attempts to find the breaking commit, no matter how many commits there are. At least we knew which PR the issue was affected by, but instead of just hot-fixing what was probably a one-liner, we had to either revert the entire new feature or read through all the changes to find the issue.

account42 4y ago
This is exactly why so many of us a vehemently opposed to squashing. But in case you still have the original refs for the PR you can run bisect on that to narrow it down - assuming that the individual commits are (somewhat) consistent states that can be built.
ddevault 4y ago
Squashing isn't the problem. What you should be doing is trying to make each commit the smallest possible atomic unit of change. Rebase is a useful tool for achieving this -- squashing, splitting, whatever. git add/commit -p also good for this.