I implemented my company's SVN to Git migration, and so I was familiar with Git notes because KDE's svn2git program[1] supports using git notes for storing information.
Unfortunately, we immediately had to rewrite everything using `git-lfs` and `git filter-repo`, so all the associations were lost and we just ended up stuffing everything into the commit message instead where people could actually see it.
Is git bisect a power user feature? I was taught git by a senior engineer early in my career and it was the first "this will save your rear" tool he showed me.
If you are working on a web app that you can bisect and retest each new version in a few seconds it's an amazing tool.
If you are working on a stack of huge server apps with 1h+ build times, and complicated start up procedures you aren't going to find besect very useful at all.
1h+ build times are probably a result of not doing something about the build times like fixing #include mess, making sure there are no redundant compiles, caching and getting better hardware.
But even if your build times are that ridiculous, git bisect is still useful because it is not just a constant time improvement - having to do log(n) builds isntead of n is going to be helpful no matter how long each build takes.
I've seen projects that take longer to link than a complete from-scratch build of the Linux kernel (and when bisecting, incremental builds do a lot for you on the later steps).
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).
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.
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.
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.
I’ve met people who use git on a daily basis and haven’t heard of bisect or even more “common” commands like stash/rebase/reset.
There are tons of folks out there for whom git usage is a necessary but background element of some other task they’re doing, and so they know to do one or two add/commit/push style flows. I’ve had many people say to me “every so often I get git errors that I don’t understand so I just delete the whole directory and clone again”
Actually, I know a lot of people who don't know stash/rebase, but they heard of git bisect. So not sure if "more common" is a fair assessment. I wonder if there are any known statistics on that.
