| ▲ | cleverdash 9 hours ago |
| 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 workflow. Right now I let Claude Code work on a feature branch and it naturally produces one big diff. Stacked PRs could be interesting if agents learned to split their own work into logical chunks. |
|
| ▲ | jillesvangurp 2 hours ago | parent | next [-] |
| It's easier to pile on a lot of changes with AI assisted workflows. And reviewing all that is definitely a challenge just because of the volume of changes. I've actually stopped pretending I can review everything in detail because it makes me a bottleneck in the process. Anything that makes reviewing easier is welcome. To me, stacked PRs seems overly complicated. It seems to boil down to propagating git rebases through stacks of interdependent branches. I'm fine with that as long as I don't have to deal with people force pushing changes and routinely rewriting upstream history. It's something you probably should do in your own private fork of a repository that you aren't sharing with anyone. Or if you are, you need to communicate clearly. But if the goal is to produce a stack of PRs that in the end merge cleanly, stacked PRs might be a good thing. As soon as you have multiple collaborators working on a feature branch force pushing can become a problem and you need to impose some rules. Because otherwise you might end up breaking people's local branches and create work for them. The core issue here is that in many teams, people don't actually fork the main repository and have push access to the main repository. Which emulates the central repository model that people were used to twenty years ago. Having push access is not normal in most OSS projects. I've actually gotten the request from some rookie developers that apparently don't get forking to "please give me access to your repository" on some of my OSS projects. A proper pull request (whether stacked or not) to an OSS project needs to be clean. If you want to work on some feature for weeks you of course need mechanisms to stay on top of up stream changes. OSS maintainers will probably reject anything that looks overly messy to merge. That's their job. |
|
| ▲ | ameliaquining 9 hours ago | parent | prev | next [-] |
| The tooling for that already exists, since a PR can consist of multiple Git commits and you can look at them separately in the UI. I don't know whether agents are any good at navigating that, but if not, they won't do any better with stacked PRs. Stacked PRs do create some new affordances for the review process, but that seems different from what you're looking for. |
| |
| ▲ | Arainach 8 hours ago | parent [-] | | Looking at multiple commits is not a good workflow: * It amounts to doing N code reviews at once rather than a few small reviews which can be done individually * Github doesn't have any good UI to move between commits or to look at multiple at once. I have to find them, open them in separate tabs, etc. * Github's overall UX for reviewing changes, quickly seeing a list of all comments, etc. is just awful. Gerrit is miles ahead. Microsoft's internal tooling was better 16 years ago. * The more commits you have to read through at once the harder it is to keep track of the state of things. | | |
| ▲ | Hamuko 8 hours ago | parent | next [-] | | >It amounts to doing N code reviews at once rather than a few small reviews which can be done individually I truly do not comprehend this view. How is reviewing N commits different from/having to do less reviews reviewing N separate pull requests? It's the same constant. | | |
| ▲ | Arainach 8 hours ago | parent | next [-] | | Small reviews allow moving faster for both the author and reviewer. A chain of commits: * Does not go out for review until the author has written all of them * Cannot be submitted even in partial form until the reviewer has read all of them Reviewing a chain of commits, as the reviewer I have to review them all. For 10 commits, this means setting aside an hour or whatever - something I will put off until there's a gap in my schedule. For stacked commits, they can go out for review when each commit is ready. I can review a small CL very quick and will generally do so almost as soon as I get the notification. The author is immediately unblocked. Any feedback I have can be addressed immediately before the author keeps building on top of it. | |
| ▲ | tcoff91 8 hours ago | parent | prev [-] | | Let's compare 2 approaches to delivering commits A, B, C. Single PR with commits A, B, C: You must merge all commits or no commits. If you don't approve of all the commits, then none of the commits are approved. 3 stacked PRs: I approve PR A and B, and request changes on PR C. The developer of this stack is on vacation. We can incrementally deliver value by merging PRs A and B since those particular changes are blocking some other engineer's work, and we can wait until dev is back to fix PR C. |
| |
| ▲ | tcoff91 8 hours ago | parent | prev [-] | | It's crazy that you're getting downvoted for this take. This isn't reddit people. You're not supposed to downvote just because you disagree. Downvotes are for people who are being assholes, spamming, etc... If you disagree with a take, reply with a rebuttal. Don't just click downvote. | | |
| ▲ | steveklabnik 8 hours ago | parent [-] | | Historically, hn etiquette is that it's fine to downvote for disagreement. This came from pg himself. That said, while he hasn't posted here for a long time, this is still in the guidelines: > Please don't post comments saying that HN is turning into Reddit. It's a semi-noob illusion, as old as the hills. https://news.ycombinator.com/newsguidelines.html | | |
|
|
|
|
| ▲ | steveklabnik 8 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | 4b11b4 8 hours ago | parent [-] | | I once threatened Claude have to learn JJ after doing some crazy git rebase gymnastics. The problem is clearly that I don't know jj | | |
| ▲ | steveklabnik 8 hours ago | parent [-] | | It sometimes will hallucinate older CLI options, because jj has changed at various times, but it's pretty decent with it at this point. The harder part is that a lot of plugins hardcode git into them. |
|
|
|
| ▲ | adamwk 9 hours ago | parent | prev | next [-] |
| Maybe there’s a git trick I don’t know, but I’ve found making small branches off each other painful. I run into trouble when I update an earlier branch and all the dependent branches get out of sync with it. When those earlier branches get rebased into master it becomes a pain to update my in-progress branches as well |
| |
| ▲ | leleat 8 hours ago | parent | next [-] | | If I understood you correctly, you want to propagate changes in a branch to other branches that depend on it? Then --update-refs is for you[1]. That way, you only need to update the "latest" branch. [1] https://andrewlock.net/working-with-stacked-branches-in-git-... | |
| ▲ | flyingcircus3 8 hours ago | parent | prev [-] | | Stacking branches for any extended period of time is definitely a poor mixing of the concepts of branches and commits. If you have a set of changes you need to keep in order, but you also need to maintain multiple silos where you can cleanly allow the code to diverge, that divergence constitutes the failure of your efforts to keep the changes in order. Until you can make it effortless, maintaining a substantial commit structure and constantly rebasing to add changes to the proper commit quickly turns into more effort than just waiting to the end and manually editing a monster diff into multiple sensible commits. But we take the challenge and tell ourselves we can do better if we're proactive. | | |
| ▲ | adamwk 8 hours ago | parent [-] | | This is what I understood as well, but it sounded like GP had success doing it; so I was curious if there was a trick I didn’t know about | | |
| ▲ | flyingcircus3 7 hours ago | parent [-] | | I take from GP that they try to make their branches small, and keep the cycle of development->review->merging small, so that the problem stacked PRs seeks to solve doesn't materialize in the first place. Stacked PRs in my experience has primarily been a request to merge in a particular order. If you're the only merger, as in GP's case, there's no need to request this of yourself. | | |
| ▲ | skydhash 2 hours ago | parent [-] | | Whenever I send a big diff. I spend some time annotating with comment first to helps the reviewer. A good summary of the changes in the description, the I annotate the diff of the PR, explaining approaches, the design of a specific changes, tricky part of the code, boilerplate,... Trying to guess the context is where the review bottleneck is, so I present it alongside the code. |
|
|
|
|
|
| ▲ | dbbk 9 hours ago | parent | prev [-] |
| If you visit the webpage it gives you integration instructions for agents |
