Most shops I've worked in use squash and merge (or rebase) always. This prevents unnecessary repo bloat as the number of devs, code base and number of commits gets large and removes all those "Typo".... "Typo again".... "Sigh. Working now (I think)" type of commits that really don't add anything meaningful to the context.

With squash and merge you get chunky, meaningful commits that (with discipline) are tagged to a specific issue/feature so it's really easy to understand the history.

You think Gerrit is any better? The way I've seen Gerrit used essentially erases the commit history with an amend, and its configured so only one person can work on a branch at a time, locking out vertical, parallel work. Maybe that's just been my experience however.

I’ve just reviewed ‘spr’, ‘git-spr’ and ‘git-grok’ which supposedly make it easier to submit a stack of prs for review. They all kinda work, I didn’t like any though. GitHub really makes it more difficult than it should be.

I think ‘stg’ with a GitHub publish/stack sync option would be a winner.