Wondering how all of those startups that implement this for GitHub feel right now.
GitHub Stacked PRs
81–90 of 548 posts
Re: GitHub Stacked PRs
#82[flagged]
Re: GitHub Stacked PRs
#83Earlier quoted context omitted.
Looking at multiple commits is not a good workflow: * It amounts to doing N code reviews at once rather than a few small reviews which can be done individually * Github doesn't have any good UI to move between commits or to look at multiple at once. I have to find them, open them in separate tabs, etc. * Github's overall UX for reviewing changes, quickly seeing a list of all comments, etc. is just awful. Gerrit is mi…
> It amounts to doing N code reviews at once rather than a few small reviews which can be done individually I truly do not comprehend this view. How is reviewing N commits different from/having to do less reviews reviewing N separate pull requests? It's the same constant.
Let's compare 2 approaches to delivering commits A, B, C.
Single PR with commits A, B, C: You must merge all commits or no commits. If you don't approve of all the commits, then none of the commits are approved.
3 stacked PRs: I approve PR A and B, and request changes on PR C. The developer of this stack is on vacation. We can incrementally deliver value by merging PRs A and B since those particular changes are blocking some other engineer's work, and we can wait until dev is back to fix PR C.
Re: GitHub Stacked PRs
#84how is this different than viewing a PR one commit at a time?
Stacked PRs track changes through updates and can be integrated progressively as they get validated.
They also allow reviewing commits individually, which is very frustrating to do without dedicated support (unless you devolve back to mailing list patch stacks).
Re: GitHub Stacked PRs
#85Earlier quoted context omitted.
Each commit can be merged independently as they're reviewed.
I don't think this is it. The main driver is that several operations in GH are scoped around a PR, not a commit. So the reason you need stacked PRs is that the layer of tooling above `git` is designed to work on logical groups of commits called a PR.
Right, the argument against: "how is this any different than splitting into single commits?" is simply: In general you want just one level above a commit which is the PR
Re: GitHub Stacked PRs
#86I might be missing something, but what I need is not "stacked PR" but a proper UI and interface to manage single commit: - merge some commits independently when partial work is ready. - mark some commit as reviewed. - UI to do interactive rebase and and squash and edit individual commits. (I can do that well from the command line, but not when using the GitHub interface, and somehow not everyone from my team is famil…
It's basically trying to bring the stacked diff workflow pioneered by Phabricator to GitHub. The idea is that it allows you to better handle working on top of stuff that's not merged yet, and makes it easier for reviewers to review pieces of a larger stack of work independently. It's really useful in larger corporate environments. I've used stacked PRs when doing things like upgrading react-native in a monorepo. It r…
> stacked diff workflow pioneered by Phabricator
Ahem, pioneered by gerrit. But actually, I'm almost certain even that wasn't original art. I think gerrit just brought it to git.
Re: GitHub Stacked PRs
#87I might be missing something, but what I need is not "stacked PR" but a proper UI and interface to manage single commit: - merge some commits independently when partial work is ready. - mark some commit as reviewed. - UI to do interactive rebase and and squash and edit individual commits. (I can do that well from the command line, but not when using the GitHub interface, and somehow not everyone from my team is famil…
Workflows can vary, but what I like:
PR/MR is an "atomic" change (ideally the smallest change that can be landed separately - smallest makes it easier to review, bisect and revert)
Individual commits (or what "versions" are in Phabricator) are used for the evolution of the PR/MR to achieve that change.
But really I have 2 use cases for the commits:
1. the PR/MR is still too big, so I split it into individual commits (I know they will land together)
2. I keep the history of the evolution of the PR/MR in the commits ("changed foo to bar cause its a better approach")
Re: GitHub Stacked PRs
#88Earlier quoted context omitted.
The tooling for that already exists, since a PR can consist of multiple Git commits and you can look at them separately in the UI. I don't know whether agents are any good at navigating that, but if not, they won't do any better with stacked PRs. Stacked PRs do create some new affordances for the review process, but that seems different from what you're looking for.
Looking at multiple commits is not a good workflow: * It amounts to doing N code reviews at once rather than a few small reviews which can be done individually * Github doesn't have any good UI to move between commits or to look at multiple at once. I have to find them, open them in separate tabs, etc. * Github's overall UX for reviewing changes, quickly seeing a list of all comments, etc. is just awful. Gerrit is mi…
It's crazy that you're getting downvoted for this take.
This isn't reddit people. You're not supposed to downvote just because you disagree. Downvotes are for people who are being assholes, spamming, etc...
If you disagree with a take, reply with a rebuttal. Don't just click downvote.
Re: GitHub Stacked PRs
#89Does it fix the current UX issue with Squash & Merge? Right now I manually do "stacked PRs" like this: main If PR B merges first, PR A can merge to main no problems. If PR A merges to main first, fixing PR B is a nightmare. The GitHub UI automatically changes the "target" branch of the PR to main, but instantly conflicts spawn from nowhere. Try to rebase it and you're going to be manually looking at every non-conflic…
[deleted]
Re: GitHub Stacked PRs
#90The biggest challenge for us are PRs that need to be coordinated across multiple repos. API + client for example. It doesn't sound like stacked PRs solve that problem, right? Description specifically states single repo.
They do not no. Afaik GitHub has little to nothing that is cross repository.