I've had failures while git bisecting, hitting commits that clearly never compiled, because I'm probably the first person to ever check them out.
I've had failures while git bisecting, hitting commits that clearly never compiled, because I'm probably the first person to ever check them out.
e.g. I'm currently working on a substantial framework upgrade to a project - I've pulled every dependency/blocker out that could be done on its own and made separate PRs for them, but I'm still left with a number of logically independent commits that by their nature will not compile on their own. I could squash e.g. "Update core framework", "Fix for new syntax rules" and "Update to async methods without locking", but I don't know that reviewers and future code readers are better served by that.
Where you have two repositories, one "polished" where every commit always passes, and another for messier dev history.
If you have expensive e2e tests, then you might want to keep a 'latest' tag on main that's only updated when those pass.