… am I moving goalposts? I do know about --first-parent and it is not intended to be a feature to make git logs readable. It gets rid of nearly the entire git history. At this point, you might as well simply go to the github page and look at merged PRs; that will actually get you something readable.

I fear you may be terribly misunderstanding the point of atomic commits and readable commit messages. Everything within a merge commit will still come up during a bisect, for example. If the commits are non-atomic and/or they are badly written, that is still an issue.

--first-parent hides the problem, and adds a new one. I'm not sure what your thinking is. Once again, what's more readable to you of all the screenshots I linked?

Not to argue in either direction, but I think you should be able to "fix" the bisect problem with a script like this:

  #!/bin/bash
  bad=$(git rev-parse "$1")
  good=$(git rev-parse "${@:2}")
  
  git bisect start "$bad" $good
  
  filter=$(echo "$good" | sed 's/^/^/' | cat <(echo "$bad") - | xargs)
  comm -13 \
      <(git rev-list --first-parent $filter | sort) \
      <(git rev-list                $filter | sort) \
      | xargs git bisect skip

I haven't tested it all too thoroughly, but from what `git bisect view` tells me, this seems to work like a `git bisect --first-parent`. I'm wondering why there is no such option...

For anyone unfamiliar with git extension scripts: You should be able to put it in an executable (`chmod +x`) file (say `git-bisect-branch`) in your $PATH to make it usable (`git bisect-branch $bad $good...`).