Multi-commit PRs vs. multiple single-commit PRs

[Vladimir Panteleev via Digitalmars-d]

On Wednesday, 22 March 2017 at 15:59:29 UTC, deadalnix wrote:
> 4 out of your 6 examples use squash.

No, and at this point I don't know if you're being willfully 
ignorant or plainly malicious.

The Gerrit/Phabricator equivalent of squashing GitHub PRs would 
be to squash multiple inter-dependent reviewed changesets after 
they've all been reviewed. Suffice to say that this is not a 
thing that happens.

There are two ways to attempt to use the Gerrit workflow on 
GitHub:

1. Use one PR per commit. This is pretty far from Gerrit, because 
there is a lot of overhead in creating and maintaining the PRs, 
and no way to indicate inter-dependent PRs in the system itself. 
Although possible in theory, it is too inconvenient to be 
practical (see earlier arguments in this thread). Gerrit has a 
lot of tooling and workflow conventions that are geared towards 
making this workflow practical, things which are completely 
absent in the GitHub world.

2. Use one PR per patch series, and review commit by commit. 
GitHub does allow reviewing a PR commit by commit, so even 
considering that it's more difficult to merge just some parts of 
a PR, and the results from the various merge strategies, I 
believe this to overall be the better solution.

Without a doubt, if GitHub provided better tooling to submit a 
patch series in which each commit gets its own first-class review 
page, and allow easily updating each part of the patch series 
without causing severe maintenance overhead for the rest, it 
would be the way to go. As things are, consider, how would you 
submit a change set consisting of 5 commits, where each one 
depends on the previous one? You would need to either waste a lot 
of time updating dependent PRs as you update earlier commits, 
waste time waiting until each commit is reviewed before 
submitting the rest, or eschew git best practices and lump things 
into as few commits as you can get away with. Whereas, when all 
the commits are on a single branch, updating changes in an early 
commit is as easy as an interactive rebase and force push.