Live data from Hacker News

GitHub Stacked PRs

github.github.com

61–70 of 548 posts

Re: GitHub Stacked PRs

#61
post #49
post #43

Earlier quoted context omitted.

Each commit can be merged independently as they're reviewed.

One of the advertised features of this is being able to merge all the PRs at once. Which would also be the case for multiple commits in a single PR.

[deleted]

Re: GitHub Stacked PRs

#62

how is this different than viewing a PR one commit at a time?

Commits are immutable and you never know which feedback goes stale when you add another commit.

I'm not a huge fan, since stacked PRs mean the underlying issues don't get addressed (reviews clearly taking too long, too much content in there), but it seems they want something that works for their customers, right now, as they work in real life.

Re: GitHub Stacked PRs

#63

As a solo dev I rarely need stacked PRs, but the underlying problem, keeping PRs small and reviewable, is real even when you're your own reviewer. I've found that forcing myself to break work into small branches before I start (rather than retroactively splitting a giant branch) is the actual discipline. The tooling just makes it less painful when you don't. Curious whether this changes anything for the AI-assisted w…

I have had a lot of success with Claude and jj, telling it to take the stack of work it's done and build me a new stack on top of trunk that's centered around ease of reviewing.

Re: GitHub Stacked PRs

#64
post #39

I find this puzzling. It does not seem to allow to stack PRs on top of other people's PRs? There is already an option to enable review comments on individual commits (see the API endpoint here: https://docs.github.com/en/rest/guides/working-with-comments... ). Self-stacking PRs seem redundant.

Still feels like an alpha version right now. I'm sure they will add it later.

Graphite (which they seem to be inspired by) has frozen branches exactly for that use case:

https://graphite.com/blog/introducing-frozen-branches

Re: GitHub Stacked PRs

#65
post #20
post #4

If only there were some way to logically break up large pull requests into smaller pieces... Some way of creating a checkpoint with a diff including your changes, and some kind of message explaining the context behind the change... some way to "commit" a change to the record of the repository...

So much effort has been spent beating git until it's just CVS with bells on.

The stacked diffs flow is much closer to the kernel flow for git than the traditional GitHub PR flow is.

Re: GitHub Stacked PRs

#66
I might be missing something, but what I need is not "stacked PR" but a proper UI and interface to manage single commit:

- merge some commits independently when partial work is ready.

- mark some commit as reviewed.

- UI to do interactive rebase and and squash and edit individual commits. (I can do that well from the command line, but not when using the GitHub interface, and somehow not everyone from my team is familiar with that)

- ability to attach a comment to a specific commit, or to the commit message.

- better way to visualize what change over time in each forced push/revision (diff of diff)

Git itself already has the concept of commit. Why put this "stacked PR" abstraction on top of it?

Or is there a difference I don't see?

Re: GitHub Stacked PRs

#67
There’s a startup callled Graphite dedicated to stacked PRs. I have been using them for a while now I always wonder why github doesn’t implement something similar to this. I probaly will try and switch to GitHub to see if it works flawlessly

Re: GitHub Stacked PRs

#68
post #43

how is this different than viewing a PR one commit at a time?

Each commit can be merged independently as they're reviewed.

I don't think this is it. The main driver is that several operations in GH are scoped around a PR, not a commit. So the reason you need stacked PRs is that the layer of tooling above `git` is designed to work on logical groups of commits called a PR.

Re: GitHub Stacked PRs

#69
Wow i really need this, we had a refactor our monorepo (dotnet 8 -> 10 and angular 19 -> 21) which resulted in many small changes (like refactoring to signals, moving components to standalone) and we try to group changes into commits by what was fixed, but this had the downside of some commits beeing huge while others small, this would have helped us alot grouping commits together and having cleaner commit messages.

Re: GitHub Stacked PRs

#70
post #25

As someone who used phabricator and mercurial, using GitHub and git again feels like going back to the stone ages. Hopefully this and jujutsu can recreate stacked-diff flow of phabricator. It’s not just nice for monorepos. It makes both reviewing and working on long-running feature projects so much nicer. It encourages smaller PRs or diffs so that reviews are quick and easy to do in between builds (whereas long pull…

I'm so glad git won the dvcs war. There was a solid decade where mercurial kept promoting itself as "faster than git*†‡" and every time I tried it wound up being dog slow (always) or broken (some of the time). Git is fugly but it's fast, reliable, and fugly, and I can work with that.
Post reply on HN