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…
Stacked PRs are now live on GitHub
261–270 of 308 posts
Re: Stacked PRs are now live on GitHub
#262Is 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 :)
Re: Stacked PRs are now live on GitHub
#263I 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
#264Earlier 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.
Re: Stacked PRs are now live on GitHub
#265Earlier 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.
Re: Stacked PRs are now live on GitHub
#266I'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…
Re: Stacked PRs are now live on GitHub
#267Re: Stacked PRs are now live on GitHub
#268Earlier 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?
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
#269Earlier 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
Re: Stacked PRs are now live on GitHub
#270Earlier 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.
(I would love to be proven wrong if there's been some progress that I didn't get the memo about ^^)