8 ms·

Just taking a step back, it is SO COOL to me to be reading about stacked pull requests on HN. When we started graphite.dev years ago that was a workflow most d

Just taking a step back, it is SO COOL to me to be reading about stacked pull requests on HN. When we started graphite.dev years ago that was a workflow most developers had never heard of unless they had previously been at FB / Google. Fun to see how fast code review can change over 3-4yrs :)

jacobegold 1y ago
hell yeah
foota 1y ago
I miss the fig workflow :-(
- kyrra 1y ago
  Try `jj`, as others have mentioned. It's being built by the team that built/maintains fig, and the are porting all their learnings into that.
  - ndr 1y ago
    jj is cool solo, but it doesn't seem of much help when maintaining a stack of PRs neatly updated on github
    - abound 1y ago
      It requires a bit of scripting between the `gh` CLI and `jj`, but it's totally doable to maintain even complex stacks of PRs on GitHub with jj. One thing I've found at $DAYJOB is that I have to set the PR's "base" branch to "main" before I push updated commits (and then switch it back to the parent after), otherwise CI thinks my PR contains everything on main and goes nuts emailing half the company to come review it.
      - ndr 1y ago
        Is there something that does this? I've played with git town which is great for what it is. But at $DAYJOB we are now all on graphite and that stacking is super neat. The web part is frustratingly slow, but they got stacking working really well.
        jacobegold 1y ago
        we have a big effort in the works to improve web perf! where specifically are you seeing slowness in the app — what flows, what pages, etc?
        ndr 1y ago
        Super glad to hear! The worst offender is a slack notification[0] deep link into a PR I need to review. It loads in stages, and the time from click to first diff is often so frustratingly long that I end up copying the PR ID and going to GitHub instead. Sometimes I give up while Graphite is still loading and use the shortcut C-G to go to GitHub. The second issue might be the landing page. I love what it shows compared to GitHub, but it's often slow to display loading blocks for things that haven’t even changed. Reloads are usually fast after that — until sometime later, maybe a day, when it slows down again. I don't know why it feels worse than Linear, even though there are clearly many similarities in how it's supposed to load. The guest instance isn’t so much about loading speed, but usage speed. When I submit a stack of PRs, I get a nice carousel to fill in PR titles/descriptions and choose where to publish each PR. What’s missing for me there is access to files and diffs, so I can re-review before publishing. I often end up closing it and going back to the PR list instead. [0] Thank God for those! You've made them much more useful than GitHub's. Also, the landing page is far more helpful in terms of what’s displayed.
benreesman 1y ago
I'm a pre-mercurial arcanist refugee who tends to promote Graphite in teams that are still struggling with mega-PRs and merge commits and other own goal GitHub-isms. Big fan in general even with the somewhat rocky scaling road we've been on :) And I very much appreciate both the ambition and results that come from making it interop with PRs, its a nightmare problem and its pretty damned amazing it works at all, let alone most of the time. I would strongly lobby for a prescriptive mode where Graphite initializes a repository with hardcore settings that would allow it to make more assumptions about the underlying repo (merge commits, you know the list better than I do). I think that's what could let it be bulletproof.
- tomasreimers 1y ago
  We've talked about a "safe mode" where we initialize it similar to JJ - such that you can no longer directly run git commands without funneling them thru graphite, but which would make it bulletproof. Would that be interesting?
  - benreesman 1y ago
    I think jujitsu is interesting it it's own right! It seems non-obvious that you would have to prohibit git commands in general, they're already "buyer beware" with the current tool (and arcanist for that matter). Certainly a "strict mode" where only well-behaved trees could interact with the tool creates scope for all kinds of performance and robustness optimizations (and with reflog bisecting it could even tell you where you went off script). I was more referring to the compromises that gt has to make to cope with arbitrary GitHub PRs seem a lot more fiddly than directly invoking git, but that's your area of expertise and my anecdote! Broad strokes I'm excited for the inevitable decoupling of gt from GitHub per se, it was clearly existential for zero to one, but you folks are a first order surface in 2025. Keep it up!
paulddraper 1y ago
Dude, I love Graphite. Best AI code review, hands down. (And I’ve tried a few.)
vinnymac 1y ago
Just signed up, looks like everything I ever wanted
globular-toast 1y ago
As someone who already breaks tasks into atomic (or near atomic) pieces and always has done, is this just submitting a PR for each commit as you go? How does it work for breaking changes? Requires use of feature flags?
- gen220 1y ago
  Sort of, yeah! It lends itself well to a 1 PR = 1 commit philosophy. Every PR has to pass CI to be mergeable. If you want to make a CI-breaking change, putting that behind a feature flag is one valid strategy. I'd recommend giving it a try to see what it's like. The `gt`/onboarding tour is pretty edifying and brief. It's likely that you'll find that `gt` is "enabling" workflows that you've already found efficient solutions for, because it's essentially an opinionated and productive subset of git+github. But it comes with some guardrails and bells and whistles that makes it both (1) easier for devs who are new to trunk-based dev to grok and (2) easier for seasoned devs to do essentially the same work they were already doing with fewer clicks and less `git`-fu.
thinkindie 1y ago
Given the security incident that happened to CodeRabbit I’m a bit less enthusiastic about testing out new tools that have LLMs and my codebase under the same tool. What can be a very nice experiment to try something new can easily become a security headache to deal with.
- vlovich123 1y ago
  I don’t understand. By LLMs you’re referring to the optional LLM review graphite offers as an additional purchase on product? I’m not sure I understand the risk concern.
mytailorisrich 1y ago
Stacked pull requests seem to add a layer of complexity to solve a problem that should and can be avoided in the first place. Frequent, small changes are really a good practice. Then we have things like trunk-based development and continuous integration.
- radlad 1y ago
  Stacked PRs allow me to post frequent, small changes without waiting for a review between each one.
  - mytailorisrich 1y ago
    Well, you don't need stacked PRs for that... I think stacked PRs are a symptoms of the issues the underlying workflow (feature branches with blocking reviews) has.
    - ncruces 1y ago
      “What you'll do next and in what way” is often an important tool to put the small changes into context. Stacked pull requests can be an important tool to enable “frequent, small changes” IMO. Sure, I can use a single pull request and a branch on top of that, but then it's harder for others to leave notes on the future, WIP, steps. A common situation is that during code review I create a few alternative WIP changes to communicate to a reviewer how I might resolve a comment; they can do the same, and share it with me. Discussion can fork to those change sets. Gerrit is much closer to my desired workflow than GitHub PRs.
      - mytailorisrich 1y ago
        From a continuous integration perspective my understanding is that stacked pulled requests do not make change more frequent if we define a "change" as being committed on the master branch. They only split the feature branch into smaller chunks. On the other hand, I do take your point about context over a number of consecutive changes. But, to me, "creating a few alternative WIP changes to communicate to a reviewer" indicates an issue with code reviews. I don't think code reviews are the time to propose alternative implementations, even if you have a "better" idea unless the code under review is broken.
m11a 1y ago
Graphite seems cool, it’s just unfortunately quite expensive and sometimes hard to convince procurement/etc to invest in when it has a noticeable cost involved. So I’m really hoping something like Graphite becomes open-source, or integrated into GitHub.
- sywhang 1y ago
  git-spice is completely open source and free: https://abhinav.github.io/git-spice/ https://abhinav.github.io/git-spice/
- akshayshah 1y ago
  git-spice does everything I liked from Graphite, but it’s fully open source and easy to adopt piecemeal. https://abhinav.github.io/git-spice/ https://abhinav.github.io/git-spice/

jacobegold 1y ago

hell yeah

foota 1y ago

I miss the fig workflow :-(

kyrra 1y ago
Try `jj`, as others have mentioned. It's being built by the team that built/maintains fig, and the are porting all their learnings into that.
- ndr 1y ago
  jj is cool solo, but it doesn't seem of much help when maintaining a stack of PRs neatly updated on github
  - abound 1y ago
    It requires a bit of scripting between the `gh` CLI and `jj`, but it's totally doable to maintain even complex stacks of PRs on GitHub with jj. One thing I've found at $DAYJOB is that I have to set the PR's "base" branch to "main" before I push updated commits (and then switch it back to the parent after), otherwise CI thinks my PR contains everything on main and goes nuts emailing half the company to come review it.
    - ndr 1y ago
      Is there something that does this? I've played with git town which is great for what it is. But at $DAYJOB we are now all on graphite and that stacking is super neat. The web part is frustratingly slow, but they got stacking working really well.
      - jacobegold 1y ago
        we have a big effort in the works to improve web perf! where specifically are you seeing slowness in the app — what flows, what pages, etc?
        ndr 1y ago
        Super glad to hear! The worst offender is a slack notification[0] deep link into a PR I need to review. It loads in stages, and the time from click to first diff is often so frustratingly long that I end up copying the PR ID and going to GitHub instead. Sometimes I give up while Graphite is still loading and use the shortcut C-G to go to GitHub. The second issue might be the landing page. I love what it shows compared to GitHub, but it's often slow to display loading blocks for things that haven’t even changed. Reloads are usually fast after that — until sometime later, maybe a day, when it slows down again. I don't know why it feels worse than Linear, even though there are clearly many similarities in how it's supposed to load. The guest instance isn’t so much about loading speed, but usage speed. When I submit a stack of PRs, I get a nice carousel to fill in PR titles/descriptions and choose where to publish each PR. What’s missing for me there is access to files and diffs, so I can re-review before publishing. I often end up closing it and going back to the PR list instead. [0] Thank God for those! You've made them much more useful than GitHub's. Also, the landing page is far more helpful in terms of what’s displayed.

benreesman 1y ago

I'm a pre-mercurial arcanist refugee who tends to promote Graphite in teams that are still struggling with mega-PRs and merge commits and other own goal GitHub-isms. Big fan in general even with the somewhat rocky scaling road we've been on :) And I very much appreciate both the ambition and results that come from making it interop with PRs, its a nightmare problem and its pretty damned amazing it works at all, let alone most of the time. I would strongly lobby for a prescriptive mode where Graphite initializes a repository with hardcore settings that would allow it to make more assumptions about the underlying repo (merge commits, you know the list better than I do). I think that's what could let it be bulletproof.

tomasreimers 1y ago
We've talked about a "safe mode" where we initialize it similar to JJ - such that you can no longer directly run git commands without funneling them thru graphite, but which would make it bulletproof. Would that be interesting?
- benreesman 1y ago
  I think jujitsu is interesting it it's own right! It seems non-obvious that you would have to prohibit git commands in general, they're already "buyer beware" with the current tool (and arcanist for that matter). Certainly a "strict mode" where only well-behaved trees could interact with the tool creates scope for all kinds of performance and robustness optimizations (and with reflog bisecting it could even tell you where you went off script). I was more referring to the compromises that gt has to make to cope with arbitrary GitHub PRs seem a lot more fiddly than directly invoking git, but that's your area of expertise and my anecdote! Broad strokes I'm excited for the inevitable decoupling of gt from GitHub per se, it was clearly existential for zero to one, but you folks are a first order surface in 2025. Keep it up!

paulddraper 1y ago

Dude, I love Graphite. Best AI code review, hands down. (And I’ve tried a few.)

vinnymac 1y ago

Just signed up, looks like everything I ever wanted

globular-toast 1y ago

As someone who already breaks tasks into atomic (or near atomic) pieces and always has done, is this just submitting a PR for each commit as you go? How does it work for breaking changes? Requires use of feature flags?

gen220 1y ago
Sort of, yeah! It lends itself well to a 1 PR = 1 commit philosophy. Every PR has to pass CI to be mergeable. If you want to make a CI-breaking change, putting that behind a feature flag is one valid strategy. I'd recommend giving it a try to see what it's like. The `gt`/onboarding tour is pretty edifying and brief. It's likely that you'll find that `gt` is "enabling" workflows that you've already found efficient solutions for, because it's essentially an opinionated and productive subset of git+github. But it comes with some guardrails and bells and whistles that makes it both (1) easier for devs who are new to trunk-based dev to grok and (2) easier for seasoned devs to do essentially the same work they were already doing with fewer clicks and less `git`-fu.

thinkindie 1y ago

Given the security incident that happened to CodeRabbit I’m a bit less enthusiastic about testing out new tools that have LLMs and my codebase under the same tool. What can be a very nice experiment to try something new can easily become a security headache to deal with.

vlovich123 1y ago
I don’t understand. By LLMs you’re referring to the optional LLM review graphite offers as an additional purchase on product? I’m not sure I understand the risk concern.

mytailorisrich 1y ago

Stacked pull requests seem to add a layer of complexity to solve a problem that should and can be avoided in the first place. Frequent, small changes are really a good practice. Then we have things like trunk-based development and continuous integration.

radlad 1y ago
Stacked PRs allow me to post frequent, small changes without waiting for a review between each one.
- mytailorisrich 1y ago
  Well, you don't need stacked PRs for that... I think stacked PRs are a symptoms of the issues the underlying workflow (feature branches with blocking reviews) has.
  - ncruces 1y ago
    “What you'll do next and in what way” is often an important tool to put the small changes into context. Stacked pull requests can be an important tool to enable “frequent, small changes” IMO. Sure, I can use a single pull request and a branch on top of that, but then it's harder for others to leave notes on the future, WIP, steps. A common situation is that during code review I create a few alternative WIP changes to communicate to a reviewer how I might resolve a comment; they can do the same, and share it with me. Discussion can fork to those change sets. Gerrit is much closer to my desired workflow than GitHub PRs.
    - mytailorisrich 1y ago
      From a continuous integration perspective my understanding is that stacked pulled requests do not make change more frequent if we define a "change" as being committed on the master branch. They only split the feature branch into smaller chunks. On the other hand, I do take your point about context over a number of consecutive changes. But, to me, "creating a few alternative WIP changes to communicate to a reviewer" indicates an issue with code reviews. I don't think code reviews are the time to propose alternative implementations, even if you have a "better" idea unless the code under review is broken.

m11a 1y ago

Graphite seems cool, it’s just unfortunately quite expensive and sometimes hard to convince procurement/etc to invest in when it has a noticeable cost involved. So I’m really hoping something like Graphite becomes open-source, or integrated into GitHub.

sywhang 1y ago
git-spice is completely open source and free: https://abhinav.github.io/git-spice/ https://abhinav.github.io/git-spice/
akshayshah 1y ago
git-spice does everything I liked from Graphite, but it’s fully open source and easy to adopt piecemeal. https://abhinav.github.io/git-spice/ https://abhinav.github.io/git-spice/