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

211–220 of 308 posts

Re: Stacked PRs are now live on GitHub

#211

Post by rendaw »

ollysb wrote: post #185
nirvdrum wrote: post #183

Earlier quoted context omitted.

Thanks for mentioning this. It seemed odd to me, too, so I spent some time trying to work it out. As a reviewer, I'm not sure how I'm supposed to assess database or API changes without knowing how they're intended to be used. And deploying them independently seems odd, too, especially if you need to roll it all back. I think in my ideal world there would be a clean history and I could review a PR commit-by-commit. Bu…

This is my confusion, we already have commits to bundle changes, why not simply allow commits to be reviewed independently within a pr?

Doesn't this have the same issue? If you need database changes that also need query changes or api changes, then you need to modify multiple commits.

Re: Stacked PRs are now live on GitHub

#212

Post by ahoka »

sunshowers wrote: post #174
Groxx wrote: post #172

Earlier quoted context omitted.

Mostly. You can't do "show me this commit in the stack before and after the force push" though iirc. And you can't comment on the derived diff, even though that's what you'll be reading during re-review to see what changed. GitHub constantly feels like features get requested with a one-sentence description, and then people who have never used any other major code review systems go build it without any further assista…

The seeming lack of engagement with prior art is so frustrating.

I think it's a very Microsoft thing. It's a parallel evolution of software branching from the microcomputer era.

Re: Stacked PRs are now live on GitHub

#213

Post by IshKebab »

zxspectrum1982 wrote: post #128
IshKebab wrote: post #94

Earlier quoted context omitted.

> it adds very little on top of what I was already able to do by saying "this is PR 1 out of 7, this is PR2 out of 7 and build on top of the branch that I used for PR1/7, etc". That's literally all it's supposed to do. Make that dev flow less awful so you don't have to say "by the way this PR depends on #123, I will change the target branch when that is merged" and nonsense like that.

Well, then it provides so little they could have not done anything at all as well. Useful stacked PRs would be something that uses AI to split my large branch/PR into smaller PRs for upstream to review. Claude does that for me.

It's not "so little". I've wanted this for ages. Trying to submit a chain of PRs is a horrible experience without support for it. This is nothing to do with AI.

Re: Stacked PRs are now live on GitHub

#214

Post by sunshowers »

ahoka wrote: post #212
sunshowers wrote: post #174

Earlier quoted context omitted.

The seeming lack of engagement with prior art is so frustrating.

I think it's a very Microsoft thing. It's a parallel evolution of software branching from the microcomputer era.

GitHub has a chance to get a generation of developers on to better coding practices. LLMs make it more feasible than ever to maintain high-quality patch series/stacked diffs — they can take care of all the mundane things like rebase conflicts for you. If I were in charge I would take this responsibility very seriously.

I guess the next best thing would be to port spr to this. (Probably time to start looking at this to be honest!) This makes me quite sad.

Re: Stacked PRs are now live on GitHub

#216

Post by zdc1 »

ankit84 wrote: post #177

Stacked PRs are not a new GitHub capability. They are an accessibility. Why so hype? The underlying stacked PR workflow is unchanged: 1. Create branch B from branch A. 2. Open PR A against main. 3. Open PR B against branch A. 4. Repeat for additional layers.

I've been doing this for years. Maybe adding some UI sugar around it is nice, but it really shouldn't be that much of a big deal...

Re: Stacked PRs are now live on GitHub

#217

Post by hypendev »

dastbe wrote: post #21
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…

> What's the benefit of this type of stacked PRs over a well-curated set of commits, and reviewing per commit? For the people who work with stacked diffs (in phab/otherwise) this is exactly what they'd consider reviewing a well-curated set of commits one-by-one. One distinction is that cognitively a unit of review (a PR, a diff) remains a single bound change. Comments are focused on that change and the PR does not gr…

But couldnt you just create a PR2 that targets your PR1 branch? What does stack contribute that multiple PRs targeting each other dont?

i.e. like this where each one targets prior PR1 db_migrations PR2 backend_base PR3 adds_frontend_scoobydoodle PR4 adds_some_landing_page_thingy PR5 probably_have_to_fix_something

Or is stacks just a feature built to make this type of PR stacking easier to review?

Re: Stacked PRs are now live on GitHub

#218

Post by hypendev »

tao_oat wrote: post #26
Insimwytim wrote: post #23

I feel like many people (and industry in general) complicate things unnecessary. Stacked pull requests break large changes into small, reviewable pull requests. That's how pull requests are supposed to be, no? If yours aren't that - you ought to rewrite them. With stacks, you can independently review and check each pull request, then merge everything together in one click. Why would I want to do that instead merging…

Here's a common flow where I find stacked PRs are useful: - I want to build feature X - Ah, but it would work better if I refactored the module first - I refactor then build feature X - There's then some additional (and optional) cleanup work As a reviewer I wouldn't want to see all this in a single PR, and the changes depend on each other so I can't open multiple independent PRs. Manual rebasing is fine but navigati…

Why isnt refactor in its separate PR? Every developer with an ounce of thought would tell youn to:

>Do PR refactoring module A >Do PR with feature X + cleanup >Maybe PR with additional work if bigger

Re: Stacked PRs are now live on GitHub

#219

Post by hypendev »

rrradical wrote: post #18

I thought 'stacking' PRs was useful in two circumstances. 1. The PRs are across different related repos, so they literally can't be combined into one PR. 2. You want to keep producing work while the first PR is in review. So you stack subsequent PRs onto the same branch. Basically just pipelining. But this feature doesn't seem to hit either use case, and instead just seems to be a different form of stacking commits i…

>1. The PRs are across different related repos, so they literally can't be combined into one PR.

This would be such a insanely useful features for a small subset of power users that they will never deliver.

Re: Stacked PRs are now live on GitHub

#220

Post by beaker52 »

Looking at the way GitHub are selling this “feature”, I feel like some of the engineers who are going to be excited about this feature for “reviewability” reasons are, in particular, those who’ve forgotten that they should be splitting changes into multiple logical commits inside a PR. And instead of that they’re now going to use multiple, single commit branches and stack them because stacked PRs are a “new” “feature”.

And the upshot for the LLM providers is that they get to charge for n reviews, instead of one.

Post reply on HN