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.
