[tomasreimers]

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

[benreesman]

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]

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?

[m11a]

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.

[akshayshah]

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/

[sywhang]

git-spice is completely open source and free: https://abhinav.github.io/git-spice/

[mytailorisrich]

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.

[vlovich123]

I’m confused. How do you do frequent small changes and avoid stacked PRs. Do you just do a small commit, wait for a review, merge, do another small commit? Or do you make a bunch of small commits locally and only put up the next one for review when the previous one is reviewed and merged?

That’s the only models I can think of and it’s weird to advocate to have a variable time asynchronous process in the middle of your code or review loops. Seems like you’re just handicapping your velocity for no reason.

Stacked PRs are precisely about factoring out small changes into individually reviewable commits that can be reviewed and landed independently, decoupling reviewer and developer while retaining good properties like small commits that the reviewer is going to do a better job on, larger single purpose commits that the reviewer knows to spend more time on without getting overwhelmed dealing with unrelated noise, and the ability to see relationships between smaller commits and the bigger picture. Meanwhile the developer gets to land unobtrusive cleanups that serve a broader goal faster to avoid merge conflicts while getting feedback quicker on work while working towards a larger goal.

The only time stacked commits aren’t as useful is for junior devs who cants organize themselves well enough to understand how to do this well (it’s an art you have to intentionally practice at) and don’t generally have a good handle on the broader scope of what they’re working towards.

[johnmaguire]

Stacked PRs allow me to post frequent, small changes without waiting for a review between each one.

[foota]

I miss the fig workflow :-(

[kyrra]

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.

[thinkindie]

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]

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.

[globular-toast]

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]

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.

[vinnymac]

Just signed up, looks like everything I ever wanted

[paulddraper]

Dude, I love Graphite.

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

[jacobegold]

hell yeah