Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stacked PRs are now live on GitHub

github.blog

Post reply on HN
Print view View original

161–170 of 308 posts

Re: Stacked PRs are now live on GitHub

#161

Post by sunshowers »

pavon wrote: post #159
sunshowers wrote: post #149

Earlier quoted context omitted.

I apologize for being somewhat direct but what prior art did you engage with? Why are you making people create a branch for each change in a stack? Why do developers have to create new commits when iterating on the PR? Where is the proper support for interdiffs? What about change IDs? The fundamental issue with GitHub -- really, its original sin -- is that the review model is wrong. It encourages a new commit + merge…

IMO not using horrible opaque change IDs is one of the best parts of this. If I wanted it to work like Gerrit, I would just be using Gerrit.

You don't have to expose change IDs in the UI other than as a secondary thing! The current integer index would work just fine.

Re: Stacked PRs are now live on GitHub

#162

Post by chill_ai_guy »

Probably a few years too late on this. Its for a time when humans still reviewed PR's. For better or worse, that is a thing of the past. The review step has shifted heavily left and newer re-imagination of Git (like Origin) will almost certainly not have a concept of a "PR" let alone stacking them

Re: Stacked PRs are now live on GitHub

#163

Post by zelphirkalt »

mosura wrote: post #135
an0malous wrote: post #113

Earlier quoted context omitted.

the whole industry has become completely “ready, fire, aim” since 2021

GitHub has been especially bad. Ultimately they have become a monopoly so it is kind of expected.

So many things on Github are now broken or utterly unusable, that this comment is not wrong. I mean even the code viewer/display is utterly broken and doesn't even perform standard text highlighting correctly. The folding marks often make no sense or are inconsistent. If one wants to see all forks of a repo, one has to go through "insights", I think few would suspect it to be located, and it doesn't show _all_ forks, according to the number displayed next to the fork button. The list of UI issues goes on and on. But then there are also the reliability issues, things being down every 2 weeks, or is it every week by now? Difficult to keep up with it really.

Re: Stacked PRs are now live on GitHub

#164

Post by 332451b »

ahepp wrote: post #133
Okkef wrote: post #17

What's the benefit of this type of stacked PRs over a well-curated set of commits, and reviewing per commit? I think the bigger problem is that big AI PR's need a different way of reviewing. For example, the order in which the diff's are shown can make a big difference in how easy the commits are to read (e.g., function definition change first, then all call sites, then the tests). Or maybe we should go to a system w…

I don't have experience with the stacked PR workflow and often find myself asking the same questions you are. As far as I can tell, the biggest benefit of stacked PRs over just making a coherent series of commits, is that it might make it easier to start work on your second PR before you merge the first one? With human-in-the-loop coding, that sounds like it could lead to a lot of wasted work if the first PR gets sub…

For me it's hard to imagine not starting on the second PR after submitting the first one, regardless of AI or stacked PRs. For focused work I find it important to avoid context switching, stay in the zone and keep everything in my head. Wasted work in comparison feels less significant to me.

If review is fast I'd be switching back and forth between tasks throughout the day. If review is slow I might end up implementing a feature over the course of two weeks rather than two days. With reviewers in different time zones, limited time or doing their own focused work, it adds a lot of latency going back and forth for every PR rather than iterating on a stack of PRs.

Personally I find the biggest benefit is that it lets both the author and reviewers work at the pace that works for them, with reduced context switching and latency.

Re: Stacked PRs are now live on GitHub

#165

Post by zelphirkalt »

I remember having tried these on Gitlab a few years ago. One PR depending on another, depending on another ... It didn't ultimately make for a good experience. Partly that was due to Gitlab's interface, but also it wasn't necessary to complicate PRs even more.

Re: Stacked PRs are now live on GitHub

#166

Post by paxys »

ahepp wrote: post #136
paxys wrote: post #77

Earlier quoted context omitted.

You can’t merge one commit at a time in a PR. In a stack, if the first 4 parts of a feature are good to go and there’s a problem with the 5th, the whole thing doesn’t need to be blocked.

I wonder if they could have added the ability to take only certain commits from a PR though? It kinda seems like they're duplicating the "unit of change" arbitrarily, rather than just fixing the way a PR works. I think the reason I find that a bit icky is it seems like it's diverging GitHub from the underlying git tool, which I trust a lot more.

It isn't arbitrary. A branch is the unit of change. You can stack branches on top of each other and merge them one at a time. You can also keep adding to the end of the stack as needed.

Re: Stacked PRs are now live on GitHub

#167

Post by sefrost »

ptx wrote: post #158
sunshowers wrote: post #149

Earlier quoted context omitted.

I apologize for being somewhat direct but what prior art did you engage with? Why are you making people create a branch for each change in a stack? Why do developers have to create new commits when iterating on the PR? Where is the proper support for interdiffs? What about change IDs? The fundamental issue with GitHub -- really, its original sin -- is that the review model is wrong. It encourages a new commit + merge…

Doesn't GitHub do this already? If I force push the PR branch, the PR shows a message about this with a link to diff it against the previous version.

Personally I find this feature works 50% of the time, and I don’t understand why.

Re: Stacked PRs are now live on GitHub

#169

Post by ahepp »

paxys wrote: post #166
ahepp wrote: post #136

Earlier quoted context omitted.

I wonder if they could have added the ability to take only certain commits from a PR though? It kinda seems like they're duplicating the "unit of change" arbitrarily, rather than just fixing the way a PR works. I think the reason I find that a bit icky is it seems like it's diverging GitHub from the underlying git tool, which I trust a lot more.

It isn't arbitrary. A branch is the unit of change. You can stack branches on top of each other and merge them one at a time. You can also keep adding to the end of the stack as needed.

I understand that GitHub kinda ate the world on this, but using a branch PR as the basic unit of change seems like an arbitrary choice to me.

Torvalds invented Git for work on the Linux kernel, and the basic unit of change there is commits over email. It's not uncommon for them to take some commits but reject others.

Which isn't meant to say "pull requests are obviously wrong and commits over email are obviously correct", but rather to point out that the idea of a take-it-or-leave-it branch isn't some kind of natural unit of contribution

https://lkml.iu.edu/hypermail/linux/kernel/1402.2/00508.html

https://lkml.indiana.edu/2011.2/05416.html

https://lkml.iu.edu/2409.0/00960.html

https://lkml.iu.edu/hypermail/linux/kernel/2510.3/01369.html

Post reply on HN