The question ultimately becomes, what do you care about more: recording every little change that's ever made, so you have a record of every time someone sneezed, or do you want a more coherent narrative that can easily be bisected? To my mind, half the reason to have code reviews and continuous integration is to make sure that the project history is coherent and bisectable.
Some might argue that non-pristine patches shouldn't be pushed in the first place, but let's be honest: we're all human, we all make mistakes, and this is (again) why we have code reviews and CI.
I can understand having options, and I'll admit that Gerrit seems good enough to me, mostly because that's all I've used. But I'll counter that successive patches are recorded in the history of Gerrit, along with commentary and the back and forth. I can see the pros to having smaller isolated commits, but one best practice recommends writing the tests first (and having them fail), then write the feature; in this workflow, you would not want to push failing tests separately because it would break bisect, and the CI won't let it through anyway.
First of all, Gerrit groups the related commits together in two ways:
1) As a list of dependencies: "This commit depends on; this commit is depended on by."
2) If you develop your feature on a topic branch (and you should), when you push the commits to gerrit you can (and should) specify the topic. The related changes are then grouped by topic. ("git push origin HEAD:refs/for/master/topic_name")
Second, the reason this workflow is superior is that it requires each commit to be individually reviewed (and hopefully verified), and what ends up getting merged is a clean topic branch, with no bad commits.
Contrast this to the other workflow, and I'll use GitHub's Pull Request as the example. Typically what's reviewed is not the individual commits on a topic branch, but rather just the diff between the tip of that branch and the merge base between it and where it's to be merged. In this workflow the individual commits are often not even looked at. So you can have this series of commits on a topic branch:
When reviewing that in GitHub, you'd typically just review the total diff introduced by all 5 commits, and if it looks good, you merge all 5. Also, typically the CI system builds just 5 or the result of 5 merged into its destination branch. So now your history has the two fixup commits in it that don't belong there.With the Gerrit-style workflow the fixups never enter the main branch, since instead you'd have squashed them into their respective commits. You'd also hopefully configure your CI system to verify each commit individually.
Further, on a decently sized topic, I find it easier to review a series of smaller changes, vs a huge diff.
It should be noted that this style of reviewing individual diffs is inspired by how reviews are done over mailing lists (Linux, Git, etc).
That said, once all the commits on a topic have been reviewed and perfected, it is often nice to be able to see the final diff of what is to be merged. With Gerrit you'd have to do that externally (via gitweb or by downloading the topic branch and diffing it locally against its destination).
Have this as a feature in Gerrit proper has been discussed and is somewhat contentious among its developers - https://groups.google.com/forum/#!topic/repo-discuss/FBJl5wW...