I agree. I have absolutely no idea what was changed in most of those commits. If I relied on this framework it would be a pain in the * to trace down when a potential bug was introduced, or to just get an overview of what's being worked on.
I was trying to track down a problem in the nim-lang/Nim repo, and had a similar impression. During a `git bisect` run I thought I'd made a mistake as I saw duplicate messages pop up, until I realised there are an enormous amount of duplicate messages in the repo.
A lazy scan right now shows over a hundred "make tests green again", a dozen "fix(up|)", handful of "WIP", etc. And beyond that a huge chunk are just "update <something>". Even with ~20k commits you can catch duplicates in a single unlucky bisect session.
I think I've come to the conclusion that /we/ in this subthread may be the problem though. Loads of projects are like that, and hardly anybody else cares. I suspect it just depends on how you are treating your VCS; I think it tells a story, others seem to think it just a snapshotting tool.
Thank you for this perspective: I never realized that "git bisect" is good only as long as commit messages are meaningful. I'm going to teach how to use "git" in my class next semester, and this is surely a point I will make!
I may have poorly made my point. It isn't that bisect is /only/ useful with good commit messages, but many subcommands are vastly improved when there is meaningful information about the change in the message.
For example, rebase's default output includes the previous and next commit messages when you pause to edit a commit.
E: I do like it, though. Don't want to bash on the project for no reason, just would prefer it if the maintainer tried to have better commit messages!