Live data from Hacker News

Stacked PRs are now live on GitHub

github.blog

261–270 of 308 posts

Re: Stacked PRs are now live on GitHub

#261

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…

Yeah, clean, neatly seperated and logically independent PRs are very nice for reviewers, but usually it requires one to complete the whole feature and then go back and think about the best way to seperate it into a series of smaller changes again. It works for projects like linux where there is tons of motivated manpower such that requiring authors put in a day of additional effort to make a change as presentable as…

I usually just amend commits as I go and don’t find it all that onerous. Sometimes it gets tricky, particularly if a rebase effectively changes what the code would have looked like. But, with LLMs even that’s gotten much easier.

Re: Stacked PRs are now live on GitHub

#262

Is that why the menu toggle is the stack of pancakes emoji (U+1F95E)? Whimsy is fine but that change made me super suspicious about what I was looking at.

We've been using the pancake emoji internally so we thought it was a fun easter egg. It'll only be up for a few hours and then will go back to the regular icons :)

I liked that. I don't have a lot of good things to say about GitHub these days -- Microsoft has not been a kind owner -- so I found that moment of silliness encouraging.

Re: Stacked PRs are now live on GitHub

#263
This was the feature I wanted the most on Github... until I started using jj.

I know that jj isn't for everyone, but for me it's been trivial to see the state of and update all the stacks of branches I have on the go.

Not that I don't welcome this feature; I just think I don't need it anymore.

Re: Stacked PRs are now live on GitHub

#264
post #138

Earlier quoted context omitted.

> For example, merging an entire stack is completely broken in many cases: https://github.com/github/gh-stack/discussions/212 > You can merge one by one, but if you're using squash and merge, you need a re-approval for each PR in the stack if you require reviews. This makes you lose out on arguably the biggest gain of stacked PRs. I'm struggling to imagine what it offers at all if that doesn't work! Is it just a way…

Not everybody uses squash and merge. Regular merge, I imagine, would work fine.

Sure, I just think that "merging one by one" defeats the purpose of stacked PRs even if you don't need re-approval. You can already avoid re-approval today without needing re-approval if you're not rebasing (which is not what I'd expect you mean by "regular merging"; it sounds like you mean just having a merge commit) by just not clicking merge until the other PR merges first, and at that point. That's what I meant by it sounding like all this offers is an icon telling you whether that other one already merged or not.

Re: Stacked PRs are now live on GitHub

#265
post #72

Earlier quoted context omitted.

We've been using the pancake emoji internally so we thought it was a fun easter egg. It'll only be up for a few hours and then will go back to the regular icons :)

Good. This change was unexpected and so unprofessional I though my browser was compromised.

Discovered the OP of https://github.com/orgs/community/discussions/203497

Re: Stacked PRs are now live on GitHub

#266

I've been using the preview for a bit, and I'm quite surprised to see them expanding the preview with so many unfixed issue. For example, merging an entire stack is completely broken in many cases: https://github.com/github/gh-stack/discussions/212 You can merge one by one, but if you're using squash and merge, you need a re-approval for each PR in the stack if you require reviews. This makes you lose out on arguably…

We're rolling out a series of bug fixes for the issues with squash merging. There's an internal system we have called CPRMC (Create Pull Request Merge Commit) that is used to evaluate whether a PR is "ready" to merge. This covers everything from mergeability (checking for merge conflicts) to rule evaluations (ensuring that approvals match the potential commit that will be created by merge) and more. This becomes part…

The feature is half baked. Just today I had to spend ~1hr untangling a mess it created. And there was no way to reorder the Stack without discarding PRs that already had many comments. I'm not an intentional an early adopter, someone on the team clicked the tooltip.

Re: Stacked PRs are now live on GitHub

#268

Earlier quoted context omitted.

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.

Does trunk use GitHub’s api to merge stacks, or does it do the integration internally / on its own?

We use GitHub's APIs. We did build a version before GitHub supported it, but it required using our credentials to push directly to the main branch. That wasn't acceptable to most of our customers, so we ended up not shipping it and waiting for GitHub support.

Using the GitHub APIs means you still preserve history and commit messages they way people expect (merges through the queue and direct merges behave the same), and it lets users guarantee that the only code our mergequeue merges is the code that was in the PR.

Re: Stacked PRs are now live on GitHub

#269
post #193

Earlier quoted context omitted.

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

Thanks! :)

Re: Stacked PRs are now live on GitHub

#270
post #202
post #189

Earlier quoted context omitted.

I'm trying to understand what you mean, because it's not obvious to me at all. If you read LKML you'll see stacked PRs has been the norm for years. I'm assuming you want the `gh stack` porcelain into the git cli? We'd first need to add PRs as a porcelain to the git cli for it to make any sense, right?

Gerrit manages stacked changes with standard git tooling, except for the tiny change-id hook. Similar stable change identifier is also what enables Jujutsu to do its magic. Standardizing around something like this would be greatly beneficial, instead a ”gh” CLI is now needed to push a commit.

JJ, Gerrit, codebutler, and I think a couple of others have all basically agreed upon a syntax for change IDs and they are converging their prior ad-hoc formats into one; but last time I checked, the request to the upstream git team of "please don't silently drop the change-id header during rebase or amend" was met with bike-shedding about all the other hypothetical benefits that alternative formats could hypothetically provide, so universal support for the header as used in practice today is still missing D:

(I would love to be proven wrong if there's been some progress that I didn't get the memo about ^^)

Post reply on HN