There's an argument that bisect is only useful if every commit is broken. If, as is often the case with my history, most commits don't compile, maybe there's an argument for squashing?
Would you not just skip those? Skipping non-compiling code is the canonical example of "git bisect skip".
You could also have a little script that does something like:
# Usage gbisect_prs bad good
git bisect start
for commit in "git log --since good --until bad"
if not commit.message.startswith("Merge pull request #"):
git bisect skip commit.hash
Turned into real code, obviously, but it'd tell git to ignore any commit that's not a PR merge.
You could also just include this into your bisect script if you're not doing it by hand, return 125 if it's not a commit you want to test.
It might make sense to squash so you only have compile-ready commits in your log.
In a sense I work this way, without the squashing. When I write a test, the build fails and nothing has been done on the application codebase so I don't commit. When I fix the build by writing new code, I commit.
Maybe I should be doing small intermediate commits and squashing the commits into one commit.
> Maybe I should be doing small intermediate commits and squashing the commits into one commit.
I would recommend trying that, or at least something similar: Try committing regularly (this is useful if you ever want to go back to a prior state while working or e.g. pick up where you left off on a different machine, etc), but reorganizing and cleaning up your topic branch (via rebase -i, etc.) into a few commits before merging (fast forward). What is "a few commits"? Well, it's a bit of a judgement call, but I just group stuff into logicially coherent units which make sense as single units of functionality. Of course you must make sure each individual commit at least builds sensibly and preferably that all tests run too.
This works as long as there are only a few commits which don't build. It fails miserably if, say, 25% of all commits don't build (don't ask). In such a situation it becomes increasingly hard to tell what actually broke whatever functionality you're interested in: The commit you end up with or N prior commits which don't build (and which is incidentally usually full of "noise").
> The commit you end up with or N prior commits which don't build (and which is incidentally usually full of "noise").
The alternative, where things are squashed together, would leave you with just one commit but it'd be those N combined together (at least, it could well be more).
You can still diff between last good and first known bad. If necessary you can branch and squash the non builders to see what happened. At worst the intermediate commits gives you the same problem you would have if you had squashed to start with.
> At worst the intermediate commits gives you the same problem you would have if you had squashed to start with.
Well, if you're going to be bisecting a lot or compilation takes a while, it saves you time to do the squash now (when you know which commits are supposed to compile and which aren't) rather than when you come back to it.
You could also have a little script that does something like:
Turned into real code, obviously, but it'd tell git to ignore any commit that's not a PR merge.You could also just include this into your bisect script if you're not doing it by hand, return 125 if it's not a commit you want to test.