5 ms·

I think GitHub's great, and I'm mostly okay with having to rely on it heavily at my day job, but I dislike how code reviews + PRs are necessarily tied to branch

I think GitHub's great, and I'm mostly okay with having to rely on it heavily at my day job, but I dislike how code reviews + PRs are necessarily tied to branches. 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.

lima 8y ago
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).
- mullsork 8y ago
  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.
- yxhuvud 8y ago
  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.
  - UK-Al05 8y ago
    My pull request branches are of the size that it only makes sense together.
  - lima 8y ago
    That's the entire point of a stacked diff workflow - you would submit smaller PRs which are the equivalent of one commit.
yxhuvud 8y ago
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.
- marcinkuzminski 8y ago
  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/17d92eee8537026494f6d1560979e61e598e6aa8...f2a4f55df5d1a994bcdc33e557e3ba17af9e1b49 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.

lima 8y ago

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).

mullsork 8y ago
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.
yxhuvud 8y ago
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.
- UK-Al05 8y ago
  My pull request branches are of the size that it only makes sense together.
- lima 8y ago
  That's the entire point of a stacked diff workflow - you would submit smaller PRs which are the equivalent of one commit.

yxhuvud 8y ago

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.

marcinkuzminski 8y ago
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/17d92eee8537026494f6d1560979e61e598e6aa8...f2a4f55df5d1a994bcdc33e557e3ba17af9e1b49 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.