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

191–200 of 308 posts

Re: Stacked PRs are now live on GitHub

#191

Post by doctorpangloss »

sameenkarim wrote: post #153
leo60228 wrote: post #61

Earlier quoted context omitted.

Is support for cross-fork stacked PRs coming in the near future? I was surprised that didn't come before the feature entered public preview, as it seems rather important for the feature to be useful on public repositories.

Yes it will be coming! The reason it's taking a bit longer is because of the automated rebase that happens after you merge part of a stack. There are some legitimate security concerns because of this so multi-fork stacks (a stack which includes multiple different forks) are probably out of the question for now. We will support a stack that is fully contained within a single fork, where the entire stack targets the or…

haha, what if you add a filter that hides merge commits?

i appreciate that you are trying to make it possible for people who vibe code solutions to problems to get code merged by people who have made GitHub their lifestyle. but surely you see how, in my framing there, the people who are worried about how their history "looks" are the problem

Re: Stacked PRs are now live on GitHub

#192

Post by gsnedders »

sunshowers wrote: post #161
pavon wrote: post #159

Earlier quoted context omitted.

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.

And enough of the time you can just match based on subject line, similar to how fixup/squash commits work with autosquash.

There’s enough ways you can match up commits, with plenty of prior art in this space.

Re: Stacked PRs are now live on GitHub

#193

Post by udave »

mattmatheson wrote: post #144
Game_Ender wrote: post #111

Earlier quoted context omitted.

Can you make sure there is good API support for stacks? We use a custom merge queue and we want it to be able to land multiple PRs from a stack at once as separate PRs. Last I checked you had to land a single PR, rebase the stack, land the next and so on. This is very expensive in CI time (and wall clock time), vs simply testing part or all of a stack in parallel then declaring those merged. In essence a robot needs…

Hey there - we worked with Sameen and the team at GitHub over the past month to get support for stacks in our Mergequeue: https://trunk.io/blog/trunk-merge-queue-now-supports-github-... They do indeed have APIs you can use in your mergequeue, I'm happy to share notes on how we built it so you can add it to your mergequeue.

lovely website animation :D

Re: Stacked PRs are now live on GitHub

#194

Post by masklinn »

sameenkarim wrote: post #114
Game_Ender wrote: post #111

Earlier quoted context omitted.

Can you make sure there is good API support for stacks? We use a custom merge queue and we want it to be able to land multiple PRs from a stack at once as separate PRs. Last I checked you had to land a single PR, rebase the stack, land the next and so on. This is very expensive in CI time (and wall clock time), vs simply testing part or all of a stack in parallel then declaring those merged. In essence a robot needs…

Yes that was one of our top priorities. For one, there's a fully public API for all stack operations. So if you don't want to use the `gh stack` CLI, you can build your own: https://docs.github.com/en/rest/pulls/stacks For merging, we have an API but had to move it to a new async method: https://github.github.io/gh-stack/reference/merge-api/ The legacy API was fully synchronous, and since stacks of multiple PRs can o…

Is there also a webhook? I don’t fancy busy-looping on dozens or hundreds of PRs for tools with large scopes of overview.

Also what about external merges? Is there a way to sanely interact with stacks when merging locally or via external tooling?

Re: Stacked PRs are now live on GitHub

#195

Post by gsnedders »

I’d still love a way to be able to rewrite commits at merge time, via Actions or otherwise.

The most obvious case is something like adding a Reviewed-By/Signed-off-by trailer based on reviewers, but there’s also a decent number of big projects that want more semantically meaningful commit identifiers (think more revision, in a numeric sense).

It seems like making merges async should make it a lot more possible to implement that!

Re: Stacked PRs are now live on GitHub

#196

Post by sunshowers »

crakhamster01 wrote: post #186
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…

Having also worked with the tools you mentioned, is using commits in-place of "versions" + squash merging all that different? 1. Adding commits means reviewers can easily diff changes to the PR 2. Squash merging preserves only 1 commit per PR ends up on trunk

I use `spr` which translates a local rebase + amend workflow into a GH-friendly new-commit + merge on the remote (which is then squashed). They are kind of equivalent from a 30k foot view but the dev experience when working with source control locally is dramatically different. And in particular I regularly have stacks of dozens of commits in flight -- if each commit were a series of commits then I would probably lose it.

Re: Stacked PRs are now live on GitHub

#197

Post by Scoring6931 »

sepeth wrote: post #11

One of the nice things about jujutsu related to this is that when you update a branch, it rebases other branches started off of that branch. I often switch to jj if I want to split my work for easy reviewing, and it works great colocated with a clone created with git.

git rebase --update-refs

If one wants to keep it to vanilla git.

Re: Stacked PRs are now live on GitHub

#198

Post by nonethewiser »

steveklabnik wrote: post #54

This is one of the biggest changes to hit GitHub in many years. I'm really glad to see something like this deployed to one of the largest forges in the world, hopefully it will expose a lot of developers to workflows that they didn't even know about before. If you buy the idea that stacking produces better software, then this also has the opportunity to really help out quite a few people.

How is this different than creating a feature branch off main then branching off that?

Re: Stacked PRs are now live on GitHub

#199

Post by Too »

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.

This emphasizes the problem even more. Only one out of ten people use the force push approach, most others add commits to the PR.

Allowing two different workflows – even within the same project – just shows the lack of strategy for how this should work.

Re-educating when and when not force-push is a holy sin is also a barrier to alignment.

Re: Stacked PRs are now live on GitHub

#200

Post by OtomotO »

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.

They are a monopoly in certain regions of the world.

Even though I live in a western country, just one of my clients after all these years of being self-employed, uses GitHub.

Nobody else would ever use it. And why would they? Especially for proprietary applications.

Post reply on HN