[CJefferson]

I don't mind rebasing a single commit, but I hate it when people rebase a list of commits, because that makes commits which never existed before, have probably never been tested, and generally never will be.

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.

[Marsymars]

Sometimes it feels like the least-bad alternative.

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.

[wonger_]

I wonder how relevant and feasible this workflow would be: https://graydon2.dreamwidth.org/1597.html

Where you have two repositories, one "polished" where every commit always passes, and another for messier dev history.

[capitainenemo]

In mercurial you could have those in phase hidden for future reference. In jujutsu you can have those in a local set, but not push upstream. Only unfortunate thing with jujutsu is because it is trying to be a git overlay, you lose state that a mercurial clone on another machine would have.