[poplarstand]

I agree. Part of the motivation for this post is that I've been doing triage on a maimed branch that got incorrectly squashed.

That being said, the workflow for this project is unlikely to change. And, to be fair, the workflow has its benefits. The project history is very clean, PR code reviews are straightforward, etc.

[WorldMaker]

What's the point of "clean project history" if junior developers accidentally sometimes break entire branches? You can get "clean views" of history with merge commits with things like --first-parent. Most PR tools today let you look at branch as a whole and it doesn't matter if you squash first or not.

Rebase workflows are so much additional work and the benefits don't actually seem worth that extra work. You can use the tools already available to get most of the same "benefits" and there's a lot less likelihood of needing to do a reflog search or deep dive into squashed commmits with no merge hints left of where a hidden three way merge took the wrong path or a need to manually manage some developer's rerere cache.

I'm biased, of course, by hitting so many of these worst case scenarios and being "the only expert" to get people out of them that I just generally don't trust any workflow that involves junior developers doing lots of unsupervised squashes and rebases. I like merge commits. I like having DAG traversal options when I need them (to fix some junior developer's accidentally bad merge; to archeology my way to deeper context around bugs). Those seem like much better "benefits" than "the project history is clean".

[icedchai]

I worked at a place that used this workflow and thought it was incredibly annoying. They also had a bunch of custom git commands set up and "trained" you to use those commands. Many people did not know what they actually did, or how to get themselves out of a jam.