3 ms·

It's basically trying to bring the stacked diff workflow pioneered by Phabricator to GitHub. The idea is that it allows you to better handle working on top of

by tcoff91 6mo ago

It's basically trying to bring the stacked diff workflow pioneered by Phabricator to GitHub. The idea is that it allows you to better handle working on top of stuff that's not merged yet, and makes it easier for reviewers to review pieces of a larger stack of work independently. It's really useful in larger corporate environments. I've used stacked PRs when doing things like upgrading react-native in a monorepo. It required a massive amount of changes, and would be really hard to review as a single pull request. It has to be landed all at once, it's all or nothing. But being able to review it as smaller independent PRs is helpful. Stacking PRs is also useful even when you don't need to merge the entire stack at once.

js2 6mo ago
> stacked diff workflow pioneered by Phabricator Ahem, pioneered by gerrit. But actually, I'm almost certain even that wasn't original art. I think gerrit just brought it to git. https://www.gerritcodereview.com/about.html https://www.gerritcodereview.com/about.html
- sunshowers 6mo ago
  To my knowledge, stacked diffs were first done in the Linux kernel as stacks of patches sent over email. From there they spread to Google and Facebook. (Source: I worked on Facebook's source control team from 2012-2018 and did a lot of work to enable stacked diffs there.)
  - js2 6mo ago
    Right, I was thinking from a web-based UI. The "pull request" term is from git (AFAIK), but git itself was built to accommodate the earlier concept of mailing patches around. (Source: I've been using version control since RCS/SCCS days and contributed here and there to git in its infancy. Also an early user/contributor to Gerrit.)
    - Izkata 6mo ago
      > The "pull request" term is from git (AFAIK) Possibly from github. It got popularized there at least, encouraging forking code, and is why so many people say "pull request" when they mean "merge request".
      - js2 6mo ago
        GitHub took the "pull request" terminology from Git. A kernel developer (say) would have a bunch of changes ready in their local Git server and would request a pull from Linus, hence a pull request. There's literally a command for it: https://git-scm.com/docs/git-request-pull https://git-scm.com/docs/git-request-pull The command is so old it's still written in shell: https://github.com/git/git/blob/master/git-request-pull.sh https://github.com/git/git/blob/master/git-request-pull.sh It was first added July 27, 2005: https://github.com/git/git/commit/ab421d2c7886341c246544bc8dea43c66a44d909 https://github.com/git/git/commit/ab421d2c7886341c246544bc8d... https://lore.kernel.org/git/20050726073036.GJ6098@mythryan2.michonline.com/ https://lore.kernel.org/git/20050726073036.GJ6098@mythryan2.... But even then, it simply codified existing terminology. Ah, someone else did the research, so minimally BitKeeper had the "pull" command first and the term "pull request" falls naturally from that: https://rdnlsmith.com/posts/2023/004/pull-request-origins/ https://rdnlsmith.com/posts/2023/004/pull-request-origins/
  - p-e-w 6mo ago
    At some point, a derivative idea becomes so different from the original one that it’s a novel idea in essence. Just like SMS is ultimately a derivative of cuneiform tablets, and yet it isn’t in any meaningful sense.
    - monster_truck 6mo ago
      Imagine gettting a cuneiform tablet by courier telling you that you have unpaid parking tickets in a state you've never driven in
    - sunshowers 6mo ago
      I don't think mailing stacks of patches is that different? As someone who built this stuff it was pretty obvious to me that web-based patch stack management was a relatively small evolution over mailing lists. Tools like patchwork bridged the gap initially, and we were quite familiar with them.
  - hokumguru 6mo ago
    Congrats and thank you. You helped build one of the best devex experiences I've ever had the pleasure of working with :)
- pabs3 6mo ago
  Gerrit was forked from Rietveld. Not sure if Rietveld or Gerrit are better though. https://github.com/rietveld-codereview/rietveld https://github.com/rietveld-codereview/rietveld https://en.wikipedia.org/wiki/Rietveld_(software) https://en.wikipedia.org/wiki/Rietveld_(software) https://codereview.appspot.com/ https://codereview.appspot.com/
  - deleted 6mo ago
    [deleted]
eptcyka 6mo ago
What if main/master moves in between reviews?
- tcoff91 6mo ago
  Rebase the stack onto main.
- jrochkind1 6mo ago
  Before this feature when you were doing it manually, it was a huge problem. One of the points of this feature, is it automates rebasing the whole stack.
- mh2266 6mo ago
  you just rebase it? what's the big deal? I don't use Github but I do work at one of the companies that popularized this workflows and it is extremely not a big deal. Pull, rebase, resolve conflicts if necessary, resubmit.
- adregan 6mo ago
  You head to the farthest branch in the chain, fetch the latest main, and run `git rebase --update-refs main` (I prefer interactive mode myself) and then force push all of the branches from start to the end. 1: https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---update-refs https://git-scm.com/docs/git-rebase#Documentation/git-rebase...
  - eptcyka 6mo ago
    I know what one does manually, but how does stack make decisions here when there’s a conflict? The reason we use a rebase flow is to allow for adjusting commits that are no longer valid.
jrochkind1 6mo ago
I'm not in a large corporate environment, but that also means we're not always a well oiled machine, and sometimes i am writing faster than the reviewer can review for a period of time -- and i really need the stacking then too.
- marktani 6mo ago
  > I'm not in a large corporate environment, but that also means we're not always a well oiled machine haha, I'm sitting in a very crusty corporate environment right now and your comment made me chuckle. I get where you're coming from though, of course!
  - jrochkind1 6mo ago
    Ha, yeah, of course I know too! I should have said it different, I meant other people were talking about needing this feature for very large teams, but I find it's needed for very small teams for perhaps different reasons related to their smallness! I need to stack PR's because I need to keep writing on top of the completed PR(s) but it might be a few days until someone else can get to reviewing because there are only a few of us and we're all doing everything.
ttoinou 6mo ago
Even with one developer on a repo this sounds like useful

by tcoff91 6mo ago

js2 6mo ago

> stacked diff workflow pioneered by Phabricator Ahem, pioneered by gerrit. But actually, I'm almost certain even that wasn't original art. I think gerrit just brought it to git. https://www.gerritcodereview.com/about.html https://www.gerritcodereview.com/about.html

sunshowers 6mo ago
To my knowledge, stacked diffs were first done in the Linux kernel as stacks of patches sent over email. From there they spread to Google and Facebook. (Source: I worked on Facebook's source control team from 2012-2018 and did a lot of work to enable stacked diffs there.)
- js2 6mo ago
  Right, I was thinking from a web-based UI. The "pull request" term is from git (AFAIK), but git itself was built to accommodate the earlier concept of mailing patches around. (Source: I've been using version control since RCS/SCCS days and contributed here and there to git in its infancy. Also an early user/contributor to Gerrit.)
  - Izkata 6mo ago
    > The "pull request" term is from git (AFAIK) Possibly from github. It got popularized there at least, encouraging forking code, and is why so many people say "pull request" when they mean "merge request".
    - js2 6mo ago
      GitHub took the "pull request" terminology from Git. A kernel developer (say) would have a bunch of changes ready in their local Git server and would request a pull from Linus, hence a pull request. There's literally a command for it: https://git-scm.com/docs/git-request-pull https://git-scm.com/docs/git-request-pull The command is so old it's still written in shell: https://github.com/git/git/blob/master/git-request-pull.sh https://github.com/git/git/blob/master/git-request-pull.sh It was first added July 27, 2005: https://github.com/git/git/commit/ab421d2c7886341c246544bc8dea43c66a44d909 https://github.com/git/git/commit/ab421d2c7886341c246544bc8d... https://lore.kernel.org/git/20050726073036.GJ6098@mythryan2.michonline.com/ https://lore.kernel.org/git/20050726073036.GJ6098@mythryan2.... But even then, it simply codified existing terminology. Ah, someone else did the research, so minimally BitKeeper had the "pull" command first and the term "pull request" falls naturally from that: https://rdnlsmith.com/posts/2023/004/pull-request-origins/ https://rdnlsmith.com/posts/2023/004/pull-request-origins/
- p-e-w 6mo ago
  At some point, a derivative idea becomes so different from the original one that it’s a novel idea in essence. Just like SMS is ultimately a derivative of cuneiform tablets, and yet it isn’t in any meaningful sense.
  - monster_truck 6mo ago
    Imagine gettting a cuneiform tablet by courier telling you that you have unpaid parking tickets in a state you've never driven in
  - sunshowers 6mo ago
    I don't think mailing stacks of patches is that different? As someone who built this stuff it was pretty obvious to me that web-based patch stack management was a relatively small evolution over mailing lists. Tools like patchwork bridged the gap initially, and we were quite familiar with them.
- hokumguru 6mo ago
  Congrats and thank you. You helped build one of the best devex experiences I've ever had the pleasure of working with :)
pabs3 6mo ago
Gerrit was forked from Rietveld. Not sure if Rietveld or Gerrit are better though. https://github.com/rietveld-codereview/rietveld https://github.com/rietveld-codereview/rietveld https://en.wikipedia.org/wiki/Rietveld_(software) https://en.wikipedia.org/wiki/Rietveld_(software) https://codereview.appspot.com/ https://codereview.appspot.com/
- deleted 6mo ago
  [deleted]

eptcyka 6mo ago

What if main/master moves in between reviews?

tcoff91 6mo ago
Rebase the stack onto main.
jrochkind1 6mo ago
Before this feature when you were doing it manually, it was a huge problem. One of the points of this feature, is it automates rebasing the whole stack.
mh2266 6mo ago
you just rebase it? what's the big deal? I don't use Github but I do work at one of the companies that popularized this workflows and it is extremely not a big deal. Pull, rebase, resolve conflicts if necessary, resubmit.
adregan 6mo ago
You head to the farthest branch in the chain, fetch the latest main, and run `git rebase --update-refs main` (I prefer interactive mode myself) and then force push all of the branches from start to the end. 1: https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---update-refs https://git-scm.com/docs/git-rebase#Documentation/git-rebase...
- eptcyka 6mo ago
  I know what one does manually, but how does stack make decisions here when there’s a conflict? The reason we use a rebase flow is to allow for adjusting commits that are no longer valid.

jrochkind1 6mo ago

I'm not in a large corporate environment, but that also means we're not always a well oiled machine, and sometimes i am writing faster than the reviewer can review for a period of time -- and i really need the stacking then too.

marktani 6mo ago
> I'm not in a large corporate environment, but that also means we're not always a well oiled machine haha, I'm sitting in a very crusty corporate environment right now and your comment made me chuckle. I get where you're coming from though, of course!
- jrochkind1 6mo ago
  Ha, yeah, of course I know too! I should have said it different, I meant other people were talking about needing this feature for very large teams, but I find it's needed for very small teams for perhaps different reasons related to their smallness! I need to stack PR's because I need to keep writing on top of the completed PR(s) but it might be a few days until someone else can get to reviewing because there are only a few of us and we're all doing everything.

ttoinou 6mo ago

Even with one developer on a repo this sounds like useful