I'm not totally buying the Phabricator way, but yes, it would be so nice to be able to individually greenlight individual commits in a pull request, and when reviewing, be able to a: see all commits on top of each other on the same page without mixing their changes and b: be able to comment on commit messages.
Re:Stacked Diffs versus Pull Requests
by marcinkuzminski on Thursday October 04, 2018 @11:22AM
(#18140702)
In RhodeCode we have a similar concept that we call diff ranges. It's not available in pull-request view directly, however, users can see this on a source repo if they select a range from changelog view.
example: https://code.rhodecode.com/rhodecode-enterprise-ce/changeset...
I agree with the concept and it's sometimes very important to see how each commit produced the final combined diff.
You can do stacked diffs on GitHub by always using squash merges and rebasing on top of master, and it's a great way to get started.
It's just a lot nicer with the extra tooling on top that Phabricator and Gerrit provide (dependencies, command line tools, and so on).
It's true that you can do that indeed. Annoyingly, you have to manually rebase if you want to use the "merge & squash" feature. I don't understand why there's no "merge into one commit, rebase with master, merge onto master" feature. It's tedious to manually keep rebasing branches that were approved for review but have gone behind.
If you squash merge you just lost all the small commits that do one thing well that you spent time creating, unless you review them one by one. Bleh.
That's the entire point of a stacked diff workflow - you would submit smaller PRs which are the equivalent of one commit.
What are the chances of GitHub introducing stacked diffs (or a similar abstraction) as an option? It'd be great to try out this workflow on a non-trivial project, but it seems like a hard sell organizationally when it involves migrating to and supporting a completely different tool like Phabricator or Gerrit.