[HN Gopher] GitHub Stacked PRs
___________________________________________________________________
GitHub Stacked PRs
Author : ezekg
Score : 289 points
Date : 2026-04-13 20:36 UTC (2 hours ago)
(HTM) web link (github.github.com)
(TXT) w3m dump (github.github.com)
| ZeWaka wrote:
| Seems to mainly be useful for monorepos as currently designed.
| Or, to replace a long-lived feature/refactor branch.
| YesThatTom2 wrote:
| Whatbmakes you say that? Devs use stacked PRs in small and
| large repos today.
| ZeWaka wrote:
| Their examples show combined backend and frontend changes on
| the same monorepo in different PRs.
|
| As far as splitting work into different PRs that need
| coordinated merging, I've only ever encountered that when
| it's a long lived refactor / feature.
| Hamuko wrote:
| I think the only thing I miss from GitLab was being able to
| make merge requests depend on other merge requests, even across
| repositories. So I could make a backend repository MR depend on
| a library repository MR, and even enable auto-merge that'd fire
| when the backend MR was reviewed and the dependency was also
| merged.
| inetknght wrote:
| Cool. Now let me do it across multiple repos. I often end up with
| 10 or 20 PRs across a half dozen repos that need to be merged in
| specific order.
| throwaway9980 wrote:
| Who hurt you?
| dpcx wrote:
| Their manager who suggested that everything be a
| microservice, but everything depends on each other.
| simplyluke wrote:
| Microservices, by the sound of the original comment
| Arbortheus wrote:
| Microservices without a monorepo is hell
| Yokohiii wrote:
| They've opted for critical damage.
| whalesalad wrote:
| For sure. If you are in a monorepo this solution works but if
| you have distinct microservice repositories it would help to
| coordinate pr #827 on repo-A and pr #1092 on repo-B are related
| and need to ship in a certain order.
| ZeWaka wrote:
| Exact problem we've run into at work. We've ended up having
| to write external merge coordination in order to not break
| our dev deployments.
| ameliaquining wrote:
| How would that work? Commits in different repos aren't ordered
| relative to one another. I suppose you could have a "don't let
| me merge this PR until after this other PR is merged" feature,
| but you could do that with a GitHub Action; it doesn't really
| need dedicated backend or UI support.
| inetknght wrote:
| > _How would that work?_
|
| In practical terms: I manually write a list of PRs, and
| maintain that list in the description of each of the PRs.
| Massive duplication. But it clearly shows the merge train.
| noident wrote:
| If only there were some way to logically break up large pull
| requests into smaller pieces... Some way of creating a checkpoint
| with a diff including your changes, and some kind of message
| explaining the context behind the change... some way to "commit"
| a change to the record of the repository...
| Hamuko wrote:
| Yeah, I feel like just being able to review a PR commit-by-
| commit with a nice interface would just suffice.
| ezekg wrote:
| Not really. Without seeing the entire changeset for a PR,
| you'd have to mentally keep track of what the current state
| of everything is unless you're a commit minimalist and
| presquash.
| aunderscored wrote:
| How does that differ from this where you need to keep track
| of state and the whole change in the stack?
| ezekg wrote:
| If we're speaking strictly code review, because you can
| actually make sense of the changeset for the child PR by
| not including its unmerged parent's changeset.
| benatkin wrote:
| For me that would mean avoiding tiny commits, and I wouldn't
| want to do that
| jaredsohn wrote:
| There are tools that use LLMs to do this.
|
| I've done this manually by building a big feature branch and
| asking an LLM to extract out functionality for a portion of it.
|
| For the former, it would seem to split based on
| frontend/backend, etc. rather than what semantically makes the
| most sense and for the latter it would include changes I don't
| want and forget some I do want. But I haven't tried this a lot.
| bombcar wrote:
| So much effort has been spent beating _git_ until it 's just
| CVS with bells on.
| steveklabnik wrote:
| The stacked diffs flow is much closer to the kernel flow for
| git than the traditional GitHub PR flow is.
| landr0id wrote:
| Part of the idea behind stacked PRs is to keep your commits
| focused and with isolated changes that are meaningful.
|
| A stacked PR allows you to construct a sequence of PRs in a way
| that allows you to iterate on and merge the isolated commits,
| but blocks merging items higher in the stack until the
| foundational changes are merged.
| noident wrote:
| What can stacked PRs do that a series of well-organized
| commits in a single branch can't?
| steveklabnik wrote:
| Stacked PRs tend to encourage a series of well-organized
| commits, because you review each commit separately, rather
| than together.
|
| What they do that the single branch cannot is things like
| "have a disjoint set of reviewers where some people only
| review some commits", and that property is exactly why it
| encourages more well-organized commits, because you are
| reviewing them individually, rather than as a massive
| whole.
|
| They also encourage amending existing commits rather than
| throwing fixup commits onto the end of a branch, which
| makes the original commit better rather than splitting it
| into multiple that aren't semantically useful on their own.
| pertymcpert wrote:
| What might that be?
| bsimpson wrote:
| Finally!
|
| I never understood the PR=branch model GitHub defaulted to.
| Stacked commits (ala Phabricator/Gerrit) always jived more with
| how my brain reasons about changes.
|
| Glad to see this option. I guess I'll have to install their CLI
| thing now.
| ezekg wrote:
| My only complaint off the bat is the reliance on the GH CLI,
| which I don't use either. But maybe by the time it's GA they'll
| have added UI support.
| ZeWaka wrote:
| It seems partially exposed in the UI with that dropdown.
| There's an 'add' and 'unstack' button.
|
| Probably relies on some internal metadata.
| ameliaquining wrote:
| You can in fact do this from the web UI:
| https://github.github.com/gh-stack/guides/ui/#creating-a-
| sta...
| ezekg wrote:
| I must have missed that. Amazing! From a reviewer's POV,
| this will be so nice to at the very least remove diff noise
| for PRs built on top of another PR. I usually refrain from
| reviewing child PRs until the parent is merged and the
| child can be rebased, for the sole reason that the diffs
| are hard to review i.r.t. what came from where.
| pbrowne011 wrote:
| Interesting to see how their CLI compares with GitLab's CLI
| interface for stacked diffs (the only support they offer at the
| moment):
| https://docs.gitlab.com/user/project/merge_requests/stacked_....
| Most things are the same (up/down/top/bottom vs.
| next/prev/first/last, init vs. create), but both feel quite
| limiting. I've heard of other systems such as Gerrit that offer
| better native support, but have not tried out any for myself.
| whalesalad wrote:
| At first I thought this was a user submitted project due to the
| subdomain of github.com but then realize the subdomain is also
| github. Is this an official channel for this sort of thing?
| Surprised this isn't on the official blog.
| ZeWaka wrote:
| It's their 'GitHub' org GitHub Pages domain - it's just .com
| instead of .io (not to be confused with their gh.io link
| shortener)
| ameliaquining wrote:
| It's in private preview. Probably they'll put it in the main
| docs and such once it's open to everyone.
| varun_ch wrote:
| it's a GitHub Pages site in the @GitHub org from a repo called
| gh-stack (i.e. the repo is at https://github.com/github/gh-
| stack/).
|
| There's a special case where certain official orgs can continue
| to use github.com instead of github.io for their Pages domain,
| and that's how you end up with:
|
| https://github.github.com/gh-stack/
|
| from the code:
|
| Should Pages owned by this user be regarded as "Official GitHub
| properties"?
|
| def github_owned_pages?
| GitHub.github_owned_pages.include?(login) end
|
| # Orgs/users that are owned by GitHub and should be allowed to
| use # `github.com` URLs. # # Returns an Array of String
| User/Organization logins. ...
| topaztee wrote:
| how is this different than viewing a PR one commit at a time?
| simplyluke wrote:
| Split into individual PRs, which works better for how a lot of
| companies do code review.
| Macha wrote:
| Each commit can be merged independently as they're reviewed.
| Hamuko wrote:
| One of the advertised features of this is being able to merge
| all the PRs at once. Which would also be the case for
| multiple commits in a single PR.
| Arainach wrote:
| That's possible but not mandatory. In the current UX you
| can only approve/submit all or none.
| CharlieDigital wrote:
| 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.
| 4b11b4 wrote:
| 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
| nickcw wrote:
| I think it is conceptually the same but multiple PRs gives you
| the tools to manage the commits properly which GitHub is
| missing. You can't do the equivalent of `git rebase -i` in the
| GitHub UI to squash a fixup into a previous commit. Having each
| change in it's own PR enables that workflow using the existing
| GitHub UI.
| stephbook wrote:
| Commits are immutable and you never know which feedback goes
| stale when you add another commit.
|
| I'm not a huge fan, since stacked PRs mean the underlying
| issues don't get addressed (reviews clearly taking too long,
| too much content in there), but it seems they want something
| that works for their customers, right now, as they work in real
| life.
| masklinn wrote:
| 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).
| IshKebab wrote:
| CI runs on each PR, you get a whole PR message and
| discussion/review interface for each PR. Each PR can itself
| consist of multiple commits. You can have stacked PRs from
| different authors (though from another comment it sounds like
| they may not have implemented that).
|
| It's a big improvement (assuming they've done it right).
| dboreham wrote:
| It would be the same if commits were meaningful things. But
| typically they're not. The PR is the meaningful thing. A commit
| is something like "fix the lint error".
| chao- wrote:
| Even though moments where I would reach for it are rare, this is
| a very welcome feature. In times when I could have used it, it
| was not difficult to emulate via more branches, consistent
| naming, referencing the PRs, etc. Not difficult, but definitely
| tedious, and always left me feeling less organized than I like to
| feel.
| adamwk wrote:
| As someone who used phabricator and mercurial, using GitHub and
| git again feels like going back to the stone ages. Hopefully this
| and jujutsu can recreate stacked-diff flow of phabricator.
|
| It's not just nice for monorepos. It makes both reviewing and
| working on long-running feature projects so much nicer. It
| encourages smaller PRs or diffs so that reviews are quick and
| easy to do in between builds (whereas long pull requests take a
| big chunk of time).
| kardianos wrote:
| I continue to use gerrit explicitly because I cannot stand
| github reviews. Yes, in theory, make changes small. But if I'm
| doing larger work (like updating a vendored dep, that I still
| review), reviewing files is... not great... in github.
| tcoff91 wrote:
| Most editors have some kind of way to review github PRs in
| your editor. VSCode has a great one. I use octo.nvim since I
| use neovim.
| nine_k wrote:
| Can these tools e.g. do per-commit review? I mean, it's not
| the UI what's the problem (though it's not ideal), it's the
| whole idea of commenting the entire PR at once, partly
| ignoring the fact that the code in it changes with more
| commits pushed.
|
| Phabricator and even Gerrit are significantly nicer.
| smallmancontrov wrote:
| I'm so glad git won the dvcs war. There was a solid decade
| where mercurial kept promoting itself as "faster than git*+++"
| and every time I tried it wound up being dog slow (always) or
| broken (some of the time). Git is fugly but it's fast,
| reliable, and fugly, and I can work with that.
| Leynos wrote:
| I just used it because I preferred the UX.
| forrestthewoods wrote:
| Mercurial has a strictly superior API. The issue is solely
| that OG Mercurial was written in Python.
|
| Git is super mid. It's a shame that Git and GitHub are so
| dominant that VCS tooling has stagnated. It could be so so so
| much better!
| awesome_dude wrote:
| Whatever your opinion on one tool or another might be - it
| does seem weird that the "market" has been captured by what
| you are saying is a lesser product.
|
| IOW, what do you know that nobody else does?
| jrochkind1 wrote:
| Welcome to VHS and Betamax. the superior product does not
| always win the market.
| esafak wrote:
| That worse is better, and some people don't know better
| or care.
| dwattttt wrote:
| "better" in that sentence is very specific. Worse is also
| worse, and if you're one of the people for whom the
| "better" side of a solution doesn't apply, you're left
| with a mess that people celebrate.
| guelo wrote:
| Network effects and marketing can easily prevent better
| tools from winning.
| awesome_dude wrote:
| I mean, in the fickle world that is TECH, I am struggling
| to believe that that's what's happened.
|
| I personally went from .latest.latest.latest.use.this
| (naming versions as latest) to tortoise SVN (which I
| struggled with) to Git (which I also was one of those
| "walk around with a few memorised commands" people that
| don't actually know how to use it) to reading the fine
| manual (well 2.5 chapters of it) to being an evangalist.
|
| I've tried Mercurial, and, frankly, it was just as black
| magic as Git was to me.
|
| That's network effects.
|
| But my counter is - I've not found Mercurial to be any
| better, not at all.
|
| I have made multiple attempts to use it, but it's just
| not doing what I want.
|
| And that's why I'm asking, is it any better, or not.
| WolfeReader wrote:
| Mercurial has a more consistent CLI, a really good
| default GUI (TortoiseHg), and the ability to remember
| what branch a commit was made on. It's a much easier tool
| to teach to new developers.
| awesome_dude wrote:
| Hmm, that feels a bit subjective - I'm not going to say X
| is easier than Y when I've just finished saying that I
| found both tools to have a lot of black magic happening.
|
| But what I will point out, for better or worse, people
| are now looking at LLMs as Git masters, which is
| effectively making the LLM the UI which is going to have
| the effect of removing any assumed advantage of whichever
| is the "superior" UX
|
| I do wish to make absolutely clear that I personally am
| not yet ready to completely delegate VCS work to LLMs -
| as I have pointed out I have what I like to think of as
| an advanced understanding of the tools, which affords me
| the luxury of not having an LLM shoot me in the foot,
| that is soley reserved as my own doing :)
| forrestthewoods wrote:
| Worse products win all the time. Inertia is almost
| impossible to overcome. VHS vs Betamax is a classic. iPod
| wasn't the best mp3 player but being a better mp3 player
| wasn't enough to claw market share.
|
| Google and Meta don't use Git and GitHub. Sapling and
| Phabricator much much better (when supported by a massive
| internal team)
| aaronbrethorst wrote:
| What was the better mp3 player than the iPod?
| worldsayshi wrote:
| Maybe forgejo has a shot?
| outworlder wrote:
| > The issue is solely that OG Mercurial was written in
| Python.
|
| Are we back to "programming language X is slow" assertions?
| I thought those had died long ago.
|
| Better algorithms win over 'better' programming languages
| every single time. Git is really simple and efficient. You
| could reimplement it in Python and I doubt it would see any
| significant slowness. Heck, git was originally implemented
| as a handful of low level binaries stitched together with
| shell scripts.
| forrestthewoods wrote:
| They died because everyone knows that Python is infact
| very very slow. And that's just totally fine for a vast
| number of glue operations.
|
| It's amusing you call Git fast. It's notoriously
| problematic for large repos such that virtually every
| BigTech company has made a custom rewrite at some point
| or another!
| raincole wrote:
| This matches my experience 100%. I was about to write a
| similar comment before I see yours.
| steveklabnik wrote:
| What is kind of funny here is that you're right locally. At
| the same time, the larger tech companies (Meta and Google,
| specifically) ended up building off of hg and not git because
| (at the time, especially) git cannot scale up to their use
| cases. So while the git CLI was super fast, and the hg CLI
| was slow, "performance" means more than just CLI speed.
|
| I was never a fan of hg either, but now I can use jj, and get
| some of those benefits without actually using it directly.
| eqvinox wrote:
| I remember using darcs, but the repos I was using it with
| were so small as to performance really not mattering...
| calebio wrote:
| I miss the Phabricator review UI so much.
| montag wrote:
| Me too. And I'm speaking from using it at Rdio 15 years ago.
|
| Nothing since (Gerrit, Reviewboard, Github, Critique) has
| measured up...
| siva7 wrote:
| What a time to be alive. Stacked PRs are now a native feature of
| Github, even with first-class support for your ai agents.
| Vibeslop your whole Jira Backlog. Don't fear the merge anymore.
| Just make any feature branch a long-lived branch by stacking one
| upon another like bricks.
|
| I'm old enough to have worked with SVN and young enough to have
| taught engineers to avoid stacking PR in Git. All wisdom has been
| lost and will probably be rediscovered in another time by another
| generation.
| jollyllama wrote:
| Yeah, not sure what this solves that doing multiple PRs from
| one feature branch into another doesn't solve. But building
| behavior that into AI agents wouldn't be cool enough, I guess.
| cleverdash wrote:
| As a solo dev I rarely need stacked PRs, but the underlying
| problem, keeping PRs small and reviewable, is real even when
| you're your own reviewer. I've found that forcing myself to break
| work into small branches before I start (rather than
| retroactively splitting a giant branch) is the actual discipline.
| The tooling just makes it less painful when you don't.
|
| Curious whether this changes anything for the AI-assisted
| workflow. Right now I let Claude Code work on a feature branch
| and it naturally produces one big diff. Stacked PRs could be
| interesting if agents learned to split their own work into
| logical chunks.
| dbbk wrote:
| If you visit the webpage it gives you integration instructions
| for agents
| ameliaquining wrote:
| 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.
| Arainach wrote:
| 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 miles
| ahead. Microsoft's internal tooling was better 16 years ago.
|
| * The more commits you have to read through at once the
| harder it is to keep track of the state of things.
| Hamuko wrote:
| > _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.
| Arainach wrote:
| Small reviews allow moving faster for both the author and
| reviewer.
|
| A chain of commits:
|
| * Does not go out for review until the author has written
| all of them
|
| * Cannot be submitted even in partial form until the
| reviewer has read all of them
|
| Reviewing a chain of commits, as the reviewer I have to
| review them all. For 10 commits, this means setting aside
| an hour or whatever - something I will put off until
| there's a gap in my schedule.
|
| For stacked commits, they can go out for review when each
| commit is ready. I can review a small CL very quick and
| will generally do so almost as soon as I get the
| notification. The author is immediately unblocked. Any
| feedback I have can be addressed immediately before the
| author keeps building on top of it.
| tcoff91 wrote:
| 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.
| tcoff91 wrote:
| 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.
| steveklabnik wrote:
| Historically, hn etiquette is that it's fine to downvote
| for disagreement. This came from pg himself.
|
| That said, while he hasn't posted here for a long time,
| this is still in the guidelines:
|
| > Please don't post comments saying that HN is turning
| into Reddit. It's a semi-noob illusion, as old as the
| hills.
|
| https://news.ycombinator.com/newsguidelines.html
| tcoff91 wrote:
| Well, I stand corrected.
| adamwk wrote:
| Maybe there's a git trick I don't know, but I've found making
| small branches off each other painful. I run into trouble when
| I update an earlier branch and all the dependent branches get
| out of sync with it. When those earlier branches get rebased
| into master it becomes a pain to update my in-progress branches
| as well
| flyingcircus3 wrote:
| Stacking branches for any extended period of time is
| definitely a poor mixing of the concepts of branches and
| commits. If you have a set of changes you need to keep in
| order, but you also need to maintain multiple silos where you
| can cleanly allow the code to diverge, that divergence
| constitutes the failure of your efforts to keep the changes
| in order.
|
| Until you can make it effortless, maintaining a substantial
| commit structure and constantly rebasing to add changes to
| the proper commit quickly turns into more effort than just
| waiting to the end and manually editing a monster diff into
| multiple sensible commits. But we take the challenge and tell
| ourselves we can do better if we're proactive.
| adamwk wrote:
| This is what I understood as well, but it sounded like GP
| had success doing it; so I was curious if there was a trick
| I didn't know about
| flyingcircus3 wrote:
| I take from GP that they try to make their branches
| small, and keep the cycle of development->review->merging
| small, so that the problem stacked PRs seeks to solve
| doesn't materialize in the first place.
|
| Stacked PRs in my experience has primarily been a request
| to merge in a particular order. If you're the only
| merger, as in GP's case, there's no need to request this
| of yourself.
| leleat wrote:
| If I understood you correctly, you want to propagate changes
| in a branch to other branches that depend on it? Then
| --update-refs is for you[1]. That way, you only need to
| update the "latest" branch.
|
| [1] https://andrewlock.net/working-with-stacked-branches-in-
| git-...
| steveklabnik wrote:
| I have had a lot of success with Claude and jj, telling it to
| take the stack of work it's done and build me a new stack on
| top of trunk that's centered around ease of reviewing.
| 4b11b4 wrote:
| I once threatened Claude have to learn JJ after doing some
| crazy git rebase gymnastics. The problem is clearly that I
| don't know jj
| steveklabnik wrote:
| It sometimes will hallucinate older CLI options, because jj
| has changed at various times, but it's pretty decent with
| it at this point. The harder part is that a lot of plugins
| hardcode git into them.
| jamietanna wrote:
| Very much looking forward to getting this on Renovate - we
| require squash-merge via Merge Queue (with no per-PR override
| available in GitHub, despite asking) and so when I've got
| multiple changes, it's a lot of wrangling and rebasing
|
| If this works as smoothly as it sounds, that'll significantly
| reduce the overhead!
| sailorganymede wrote:
| Thank goodness. It was a pain to do this manually
| fweimer wrote:
| I find this puzzling. It does not seem to allow to stack PRs on
| top of other people's PRs?
|
| There is already an option to enable review comments on
| individual commits (see the API endpoint here:
| https://docs.github.com/en/rest/guides/working-with-comments...).
| Self-stacking PRs seem redundant.
| CharlieDigital wrote:
| This API leaves a comment, on the commit; not quite the same
| thing since in GH, several operations are tied to PRs and not
| to commits.
| jannes wrote:
| Still feels like an alpha version right now. I'm sure they will
| add it later.
|
| Graphite (which they seem to be inspired by) has frozen
| branches exactly for that use case:
|
| https://graphite.com/blog/introducing-frozen-branches
| bob1029 wrote:
| I feel like we already have enough abstractions in this space.
| Having _any constraints at all_ in your tools is actually a good
| thing. PRs on top of ordinary git was a good step. This seems
| like one too many.
| Yokohiii wrote:
| I honestly don't even get the PR addiction. Github has shaped
| devs workflows way too much. My best experience with git was
| when I realized that I can just have an blatantly simple
| workflow and explain it even to the junior-est dev in a few
| minutes. The reliance on github is somehow telling me that
| people stopped thinking about things they can actually control.
| TZubiri wrote:
| github.github.com? Not the first time github does something
| highly weird with their domains (like publishing docs from a
| subdomain of their public github pages service)
|
| I think they have a culture of circumventing 'official' channels
| and whoever is in charge of a thing is whoever publishes the
| thing.
|
| I think it's a great way to train users to get phished by github
| impostors, if tomorrow we see an official download from
| official.github.com or even official-downloads.github.io, sure
| it's phishy, but it's also something that github does.
|
| It's also 100% the kind of issues that, if it happens, the user
| will be blamed.
|
| I would recommend github to stop doing this stuff and have a
| centralized domain to publish official communications and
| downloads from. Github.github.com? Come on, get serious.
|
| TL;DR: DO NOT DOWNLOAD ANYTHING from this site, (especially not
| npm/npx/pnpm/bun/npjndsa) stuff. It's a Github Pages site, just
| on a subdomain that looks official, theoretically it might be no
| different from an attacker to obtain access to
| dksabdkshab.github.com than github.github.com. Even if it is
| official, would you trust the intern or whoever managed to get a
| subdomain to not get supply chained? github.github.com just think
| about it.
| varun_ch wrote:
| https://news.ycombinator.com/item?id=47614038
| TZubiri wrote:
| in github's defense. This is a bit more nuanced, less
| objectively wrong domain posture issue. It will only matter
| if one security mechanism (subdomain control) fails.
|
| The quoted microsoft examples are way worse. I see this with
| outbound email systems a lot, which is especially dangerous
| because email is a major surface of attack.
| baq wrote:
| Just when I've gotten used to having 3 or more PRs in parallel
| with a local octopus working tree with jj. Maybe my colleagues
| will see the light at least.
| enraged_camel wrote:
| The 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.
| masklinn wrote:
| They do not no. Afaik GitHub has little to nothing that is
| cross repository.
| jenadine wrote:
| I 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 familiar with that)
|
| - ability to attach a comment to a specific commit, or to the
| commit message.
|
| - better way to visualize what change over time in each forced
| push/revision (diff of diff)
|
| Git itself already has the concept of commit. Why put this
| "stacked PR" abstraction on top of it?
|
| Or is there a difference I don't see?
| tcoff91 wrote:
| 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 required a massive amount of changes,
| and would be really hard to review as a single pull request. It
| has to be landed all at once, it's all or nothing. But being
| able to review it as smaller independent PRs is helpful.
|
| Stacking PRs is also useful even when you don't need to merge
| the entire stack at once.
| js2 wrote:
| > 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.
|
| https://www.gerritcodereview.com/about.html
| sunshowers wrote:
| To my knowledge, stacked diffs were first done in the Linux
| kernel as stacks of patches sent over email. From there
| they spread to Google and Facebook. (Source: I worked on
| Facebook's source control team from 2012-2018 and did a lot
| of work to enable stacked diffs there.)
| js2 wrote:
| Right, I was thinking from a web-based UI. The "pull
| request" term is from git (AFAIK), but git itself was
| built to accommodate the earlier concept of mailing
| patches around. (Source: I've been using version control
| since RCS/SCCS days and contributed here and there to git
| in its infancy. Also an early user/contributor to
| Gerrit.)
| eptcyka wrote:
| What if main/master moves in between reviews?
| tcoff91 wrote:
| Rebase the stack onto main.
| jrochkind1 wrote:
| Before this feature when you were doing it manually, it was
| a huge problem. One of the points of this feature, is it
| automates rebasing the whole stack.
| jrochkind1 wrote:
| I'm not in a large corporate environment, but that also means
| we're not always a well oiled machine, and sometimes i am
| writing faster than the reviewer can review for a period of
| time -- and i really need the stacking then too.
| xixixao wrote:
| 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")
| mikeocool wrote:
| Constantly rewriting git history with squashes, rebases, manual
| changes, and force pushes has always seemed like leaving a
| loaded gun pointed at your foot to me.
|
| Especially since you get all of the same advantages with plain
| old stream on consciousness commits and merges using:
|
| git merge --no-ff
|
| git log --first-parent
|
| git bisect --first-parent
| OJFord wrote:
| Until someone merges master into their feature branch rather
| than rebasing it. (And then that branch later gets merged.)
| OptionOfT wrote:
| I agree. PR merges for me are bisect points. That's when
| changes are introduced. Individual commits don't even always
| build.
|
| And I don't rebase or squash because I need provenance in my
| job.
| MrJohz wrote:
| I find rebases are only a footgun because the standard git
| cli is so bad at representing them - things like --force
| being easier to write than --force-with-lease, there being no
| way to easily absorb quick fixes into existing commits,
| interdiffs not really being possible without guesswork,
| rebases halting the entire workflow if they don't succeed,
| etc.
|
| I've switched over pretty much entirely to Jujutsu (or JJ),
| which is an alternative VCS that can use Git as its backend
| so it's still compatible with Github and other git repos. My
| colleagues can all use git, and I can use JJ without them
| noticing or needing to care. JJ has merges, and I still use
| them when I merge a set of changes into the main branch once
| I've finished working on it, but it also makes rebases really
| simple and eliminates most of the footguns. So while I'm
| working on my branch, I can iteratively make a change, and
| then squash it into the commit I'm working on. If I refactor
| something, I can split the refactor out so it's in a separate
| commit and therefore easiest to review and test. When I get
| review feedback, I can squash it directly into the relevant
| commit rather than create a new commit for it, which means
| git blame tends to be much more accurate and helpful - the
| commit I see in the git blame readout is always the commit
| that did the change I'm interested in, rather than maybe the
| commit that was fixing some minor review details, or the
| commit that had some typo in it that was fixed in a later
| commit after review but that relationship isn't clear any
| more.
|
| And while I'm working on a branch, I still have access to the
| full history of each commit and how it's changed over time,
| so I can easily make a change and then undo it, or see how a
| particular commit has evolved and maybe restore a previous
| state. It's just that the end result that gets merged doesn't
| contain all those details once they're no longer relevant.
| d0mine wrote:
| You are describing gerrit.
|
| https://www.gerritcodereview.com/
| robertwt7 wrote:
| There's a startup callled Graphite dedicated to stacked PRs. I
| have been using them for a while now I always wonder why github
| doesn't implement something similar to this. I probaly will try
| and switch to GitHub to see if it works flawlessly
| ghthor wrote:
| Yep, very happy with graphite at work.
| K0IN wrote:
| Wow i really need this, we had a refactor our monorepo (dotnet 8
| -> 10 and angular 19 -> 21) which resulted in many small changes
| (like refactoring to signals, moving components to standalone)
| and we try to group changes into commits by what was fixed, but
| this had the downside of some commits beeing huge while others
| small, this would have helped us alot grouping commits together
| and having cleaner commit messages.
| DesiLurker wrote:
| what happened to the old gerrit reviews, I loved its handling on
| incremental patchsets. github is primitive by comparison.
| ghighi7878 wrote:
| What's difference between stacked PRs and merge trains in gitlab?
| masklinn wrote:
| Merge trains are an integration method. In GitHub that's called
| merge queues.
|
| Stacked PRs are a development method, for managing changes
| which are separate but dependent on one another (stacked).
|
| The two are orthogonal they can be used together or
| independently (or not at all).
| ghighi7878 wrote:
| Ahh so stacked diffs? https://docs.gitlab.com/user/project/me
| rge_requests/stacked_...
| IshKebab wrote:
| Yes, except with a proper UI. Also while you could do this
| on GitHub before in the same way that that Gitlab feature
| works, it didn't work cross-repo so in practice it wasn't
| an option for most open source code.
|
| I can't remember if Gitlab has the same limitations but I
| do remember trying to use Gitlab's stacked diffs and
| finding them to not work very well. Can't remember why tbh.
| inerte wrote:
| Looks interesting, but it seems you need to know the final shape
| of the stack before you start creating Pull Requests. So it's
| useful if you create Pull Request A, then immediately start
| working on something that builds on top of A, create a Pull
| Request for that (while A is still a PR), then you can do A->B->C
|
| Here's something that would be useful: To break down an already
| big PR into multiples that make up a stack. So people can create
| a stack and add layers, but somehow re-order them (including
| adding something new at the first position).
| tcoff91 wrote:
| It looks like in the UI if you base a PR on another branch you
| can just check a box to make it a stack. So I don't think you
| have to know the full shape of the stack in advance unless
| you're using the cli.
|
| I use jj to stack branches so i'll just be using the UI to do
| github pr stacks.
| akersten wrote:
| Does it fix the current UX issue with Squash & Merge?
|
| Right now I manually do "stacked PRs" like this:
|
| main <- PR A <- PR B (PR B's merge target branch is PR A) <- PR
| C, etc.
|
| 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-conflicting
| change that ever happened on that branch, for no apparent reason
| (yes, the reason is that PR A merging to main created a new merge
| commit at the head of main, and git just can't handle that or
| whatever).
|
| So I don't really need a new UI for this, I need the tool to Just
| Work in a way that makes sense to anyone who wasn't Linus in 1998
| when the gospel of rebase was delivered from On High to us
| unwashed Gentry through his fingertips..
| xixixao wrote:
| Conflicts spawn most likely because PR A was squashed, and once
| you squash Git doesn't know that PR B's ancestors commits are
| the same thing as the squashed commit on main.
|
| No idea if this feature fixes this.
|
| Edit: Hopefully `gh stack sync` does the rebasing correctly
| (rebase --onto with the PR A's last commit as base)
| akersten wrote:
| > Conflicts spawn most likely because PR A was squashed, and
| once you squash Git doesn't know that PR B's ancestors
| commits are the same thing as the squashed commit on main.
|
| Yeah, and I _kind of_ see how git gets confused because the
| squashed commits essentially disappear. But I don 't know why
| the rebase can't be smart when it sees that file content
| between the eventual destination commit (the squash) is the
| same as the tip of the branch (instead of rebasing one commit
| at a time).
| gregoryl wrote:
| If I'm following correctly, the conflicts arise from other
| commits made to main already - you've implicitly caught branch
| A up to main, and now you need catch branch B up to main, for a
| clean merge.
|
| I don't see how there is any other way to achieve this cleanly,
| it's not a git thing, it's a logic thing right?
| Smaug123 wrote:
| No, it's a Git thing arising from squash commits. There are
| workflows to make it work (I've linked the cleanest one I
| know that works without force pushing), but ultimately
| they're basically all hacks.
| https://www.patrickstevens.co.uk/posts/2023-10-18-squash-
| sta...
| heldrida wrote:
| This is actually a reasonable workflow. Although requires
| some preparation. I'll try it out!
| akersten wrote:
| I've no issue with the logic of needing to update feature
| branches before merging, that's pretty bread and butter. The
| specific issue with this workflow is that the "update branch"
| button for PR B is grayed out because there are these
| hallucinated conflicts due to the new squash commit.
|
| The update branch button works normally when I don't stack
| the PRs, so I don't know. It just feels like a half baked
| feature that GitHub automatically changes the PR target
| branch in this scenario but doesn't automatically do whatever
| it takes for a 'git merge origin/main' to work.
| pastel8739 wrote:
| I agree that this is annoying and unintuitive. But I don't see
| the simplest solution here, so:
|
| All you need to do is pull main, then do an interactive rebase
| with the next branch in your stack with 'git rebase -i main',
| then drop all the commits that are from the branch you just
| merged.
| teaearlgraycold wrote:
| Wondering how all of those startups that implement this for
| GitHub feel right now.
| zaps wrote:
| sherlocked
| mc-serious wrote:
| great, I'll directly compare it to graphite.com - the main point
| really is the user interface in my opinion. Still a bit sceptical
| whether github can out-deliver here, but happy to be proven
| wrong!
|
| Has anyone already tried that was a graphite user before?
| atq2119 wrote:
| People have been building stacked PR workflows on top of GitHub
| for a while now. It's great to see that the message seems to have
| finally landed at GitHub, but what is actually new here in GitHub
| itself (i.e., not counting the gh CLI tool)?
|
| There seems to be a native stack navigation widget on the PR
| page, which is certainly a welcome addition.
|
| The most important question though is whether they finally fixed
| or are going to fix the issues that prevent submitting stacked
| PRs from forks. I don't see any indication about that on the
| linked page.
| scottfits wrote:
| cherry picking is so fragile, this is at least a step in the
| right direction
| jrochkind1 wrote:
| Well, I have been waiting for this for YEARS.
|
| Every time I try to do it manually, I wind up screwing everthing
| up.
|
| Very interested ot check it out.
| ninkendo wrote:
| > a chain of small, focused pull requests that build on each
| other -- each one independently reviewable.
|
| I have never understood what this even means.
|
| Either changes are orthogonal (and can be merged independently),
| or they're not. If they are, they can each be their own PR. If
| they're not, why do you want to _review_ them independently?
|
| If you reject change A and approve change B, nothing can merge,
| because B needs A to proceed. If you approve change A and reject
| change B, then the feature is only half done.
|
| Is it just about people wanting to _separate_ logical chunks of a
| change so they can avoid get distracted by other changes? Because
| that seems like something you can already do by just breaking a
| PR into commits and letting people look at one of those at a
| time.
|
| I've tried my best to give stacked-diff proponents the benefit of
| the doubt but _none_ of it actually makes sense to me.
| steveklabnik wrote:
| The canonical example here is a feature for a website that
| requires both backend and frontend work. The frontend depends
| on the backend, but the backend does not depend on the
| frontend. This means that the first commit is "independent" in
| the sense that it can land without the second, but the second
| is not, hence, a stack. The root of the stack can always be
| landed independently of what is on top of it, while the rest of
| the stack is dependent.
|
| > If they're not, why do you want to review them independently?
|
| For this example, you may want review from both a backend
| engineer and a frontend engineer. That said, see this too
| though:
|
| > that seems like something you can already do by just breaking
| a PR into commits and letting people look at one of those at a
| time.
|
| If you do this in a PR, both get assigned to review the whole
| thing. Each person sees the code that they don't care about,
| because they're grouped together. Notifications go to all
| parties instead of the parties who care about each section.
| Both reviews can proceed independently in a stack, whereas they
| happen concurrently in a PR.
|
| > If you approve change A and reject change B, then the feature
| is only half done.
|
| It depends on what you mean by "the feature." Seen as one huge
| feature, then yes, it's true that it's not finished until both
| land. But seen as two separate but related features, it's fine
| to land the independent change before the dependent one: one
| feature is finished, but the other is not.
| Phelinofist wrote:
| If the layers of a stack have a disjoint set of reviewers
| things are viewed in separation which might lead to issues if
| there is no one reviewing the full picture.
| steveklabnik wrote:
| That is why your forge will show that these two things are
| related to each other, and you may have the same person
| assigned to review both. It can show you this particular
| change in the context of the rest of them. But not every
| reviewer will always want to see all of the full context at
| all times.
| charcircuit wrote:
| >If you reject change A and approve change B, nothing can merge
|
| The feature is also half done in this case. The author can fix
| up the concerns the reviewer had in A and then both can be
| merged at the same time.
| esafak wrote:
| Feature B depends on feature A, but you don't need B to
| understand A. Why _wouldn 't_ you create separate PRs?? It is
| faster to review and deploy.
| fmbb wrote:
| Of course you would create separate PRs.
|
| Why would you waste time faffing about building B on top of a
| fantasy version of A? Your time is probably better spent
| reviewing your colleague's feature X so they can look at your
| A.
| ChrisArchitect wrote:
| Aside:
|
| > _This is a docs site that was made to share the spec and CLI
| for private preview customers that ended up getting picked up.
| This will move to GitHub docs once it's in public preview._
|
| (https://x.com/matthewisabel)
| WhyNotHugo wrote:
| I really don't get the point of stacked PRs.
|
| Just using git, you'd send a set of patches, which can be
| reviewed, tested and applied individually.
|
| The PR workflow makes a patch series an undivisible set of
| changes, which must be reviewed, tested and applied in unison.
|
| And stacked PRs tries to work around this issue, but the issue is
| how PRs are implemented in the first place.
|
| What you really want is the ability to review individual
| commits/patches again, rather than work on entire bundles at
| once. Stacked PRs seems like a second layer of abstraction to
| work around issues with the first layer of abstractions.
| pierrekin wrote:
| The teams that I have worked with still apply the philosophy
| you're describing, but they consider PRs to be the "commit",
| i.e. the smallest thing that is sane to apoly individually.
|
| Then the commits in the PR are not held to the standard of
| being acceptable to apply, and they are squashed together when
| the PR is merged.
|
| This allows for a work flow in which up until the PR is merged
| the "history of developing the PR" is preserved but once it is
| merged, the entire PR is applied as one change to the main
| branch.
|
| This workflow combined with stacked PRs allows developers to
| think in terms of the "smallest reviewable and applicable
| change" without needing to ensure that during development their
| intermediate states are safe to apply to main.
| eqvinox wrote:
| > How It Works
|
| > The gh stack CLI handles the local workflow [...]
|
| That's not "how it works", that's "how you['re supposed to] use
| it"... for "how it works" I would've expected something like "the
| git branches are named foo1 foo2 and foo3 and we recognize that
| lorem ipsum dolor sit amet..."
|
| ...which, if you click the overview link, it says "The CLI is not
| required to use Stacked PRs -- the underlying git operations are
| standard. But it makes the workflow simpler, and you can create
| Stacked PRs from the CLI instead of the UI." ... erm ... how
| about actually explaining what the git ops are? A link, maybe? Is
| it just the PRs having common history?
|
| ...ffs...
|
| (In case it's not obvious: I couldn't care less for using a GH
| specific CLI tool.)
| zzyzxd wrote:
| One mistake I see across many organizations is that sometimes
| they overthink how much order should matter.
|
| Sure, your application has a dependency on that database, but it
| doesn't necessarily mean you can't deploy the application before
| having a database. If possible, make it acceptable for your
| application to stay in a crashloop until your database is online.
| devmor wrote:
| I agree with you and further will add that modularity+atomicity
| are the ideal state for the vast majority of software
| applications... but in reality, most organizations can not
| afford to rewrite their software to the extent required to
| achieve this, if it wasn't planned from the start.
| alkonaut wrote:
| Let's say I have the canonical example of a stack from main via a
| backend-pr and a frontend-pr. When my stack is done I send it for
| review to one frontend reviewer and one backend reviewer.
|
| Usually when you develop a "full stack" thing you continuously
| massage the backend into place while developing frontend stuff.
| If you have 10 commits for frontend and 10 for backend, they
| might start with 5 for backend, then 5 commits to each branch to
| iron out the interface and communication, and finally 5 commits
| on the frontend. Let's call these commits B1 through B10 and F1
| through F10. Initially I have a backend branch based on main wuth
| commits B1 through B5.
|
| Then I have a frontend branch based on B5 with commits F1 through
| F5. But now I need to adjust the backend again and I make change
| B6. Now I need to rebase my frontend branch to sit on B6? And
| then I make F6 there (And so on)?
|
| And wouldn't this separation normally be obvious e.g. by paths?
| If I have a regular non-stack PR with 20 commits and 50 changed
| files, then 25 files will be in /backend and 25 in /frontend.
|
| Sure, the reviewers who only review /frontend/* might now see
| half the commits being empty of relevant changes. But is that so
| bad?
| steveklabnik wrote:
| > If you have 10 commits for frontend and 10 for backend
|
| In this model, you tend to want to amend, rather than add more
| commits. And so:
|
| > they might start with 5 for backend, then 5 commits to each
| branch to iron out the interface and communication,
|
| You don't add more commits here, you modify the commits in your
| stack instead.
|
| > Now I need to rebase my frontend branch to sit on B6?
|
| Yes, when you change something lower in the stack, the things
| on top need to be rebased. Because your forge understands that
| they're stacked, it can do this for you. And if there's
| conflicts, let you know that you need to resolve them, of
| course.
|
| But in general, because you are amending the commits in the
| stack rather than adding to it, you don't need to move anything
| around.
|
| > And wouldn't this separation normally be obvious e.g. by
| paths?
|
| In the simplest case, sure. But for more complex work, that
| might not be the case. Furthermore, you said you have five
| commits for each; within those sets of five, this separation
| won't exist.
| herpdyderp wrote:
| I thrive on stacked PRs but this sure seems like a weird way to
| implement support for it. Just have each branch point to their
| parent in the chain, the end. Just native Git. I've been longing
| for better GitHub support for this but the CLI is not where I
| need that support: just the UI.
| sroussey wrote:
| Yes! Maybe that feature will come next.
| sameenkarim wrote:
| The CLI is completely optional, you can create stacked PRs
| purely via the UI.
|
| Also the rationale for having a chain of branches pointing to
| each other was so the diff in a PR shows just the relevant
| changes from the specific branch, not the entire set of changes
| going back to the parent/trunk.
|
| Curious how you're thinking about it?
| pastel8739 wrote:
| Rebasing after merging a base branch becomes a pain though,
| when you do this. IMO the CLI will be nice to automate the
| process of rebasing each branch on its parent.
| herpdyderp wrote:
| Agreed. I do have tooling for a rebase + push flow, but it
| simply calls native git commands.
| the_gipsy wrote:
| Can we merge from GitHub UI without rewriting the commit already?
| thcipriani wrote:
| Very cool that GitHub actually put stacks in the UI vs. GitLab's
| `glab stack`[0] (which looks just like the `gh stack` part of
| GitHub's thing).
|
| One part that seems like it's going to feel a little weird is how
| merging is set up[1].
|
| That is, if I merge the bottom of the stack, it'll rebase the
| others in the stack, which will probably trigger a CI test run.
| So, if I have three patches in the stack, and I want to merge the
| bottom two, I'd merge one, wait for tests to run on the other,
| merge the second vs. merge just those two in one step (though,
| without having used it, can't be sure about how this'd work in
| practice--maybe there's some way to work around this with
| restacking?)
|
| [0]: <https://docs.gitlab.com/cli/stack/>
|
| [1]: <https://github.github.com/gh-stack/guides/stacked-
| prs/#mergi...>
| zeafoamrun wrote:
| My main question about this is does it keep review history
| properly after a rebase to restack PRs? Eg if I have reviewed PR
| for branch A and now its been rebased onto B by this tool and
| then more changes are made to A, does "review changes since" work
| in A's PR? This has been the main thing stopping me from wanting
| to use rebase to stack PRs and if they've fixed this somehow then
| I'm interested.
| dminik wrote:
| Maybe this is just a skill issue, but even with several attempts
| I just can't figure out why I would use stacked diffs/PRs. Though
| maybe that's because of the way I work?
|
| I notice a lot of examples just vaguely mention "oh, you can have
| others review your previous changes while you continue working",
| but this one doesnt make sense to me. Often times, the first set
| of commits doesn't even make it to the end result. I'm working on
| a feature using lexical, and at this point I had to rewrite the
| damn thing 3 times. The time of other devs is quite valuable and
| I can't imagine wasting it by having them review something that
| doesn't even make it in.
|
| Now, I have been in situations where I have some ready changes
| and I need to build something on top. But it's not something just
| making another branch on top + rebase once the original is merged
| wouldn't solve.
|
| Is this really worth so much hype?
| pierrekin wrote:
| We use this feature extensively at $dayjob.
|
| Imagine you have some task you are working on, and you wish to
| share your progress with people in bite sized chunks that they
| can review one at a time, but you also don't want to wait for
| their reviews before you continue working on your task.
|
| Using a stacked set of PRs you can continue producing new work,
| which depends on the work you've already completed, without
| waiting for the work you've already completed to be merged, and
| without putting all your work into one large PR.
| heldrida wrote:
| I also branch out, and rebase. Also, keep updating and rebasing
| until merged. It's tedious when PR take ages for approval, as I
| keep creating new branches on top of each other.
|
| So, when I saw this announcement seemed interesting but don't
| see the point of it yet.
| fmbb wrote:
| > Large pull requests are hard to review, slow to merge, and
| prone to conflicts. Reviewers lose context, feedback quality
| drops, and the whole team slows down.
|
| OK, yeah, I'm with you.
|
| > Stacked PRs solve this by breaking big changes into a chain of
| small, focused pull requests that build on each other -- each one
| independently reviewable.
|
| I don't get this part. It seems like you are just wasting your
| own time building on top of unreviewed code in branches that have
| not been integrated in trunk. If your reviews are slow, fix that
| instead of running ahead faster than your team can actually work.
| lopsotronic wrote:
| Interesting to see how this integrates with any release flows
| that use a lot of tags or feature flagging.
| throwatdem12311 wrote:
| Freaking finally.
|
| I've been trying to convince my boss to buy Graphite for this,
| seems like Github is getting their a* in gear after Cursor bought
| them.
|
| If Jetbrains ever implements support for them in IntelliJ I will
| be in Heaven.
| quibono wrote:
| GitLab's UI around MRs (PRs) is IMO miles better than what GH's
| been offering. Try creating a PR from branch A to main, and then
| rebasing A. GitLab handles this fine and can show you changes
| between the two revisions; GitHub is completely lost.
| Pxtl wrote:
| This feels like a workaround for git's contradictory ergonomics.
| jwpapi wrote:
| This is probably driven to be more usable with AI agents, but
| smaller prs can create more code as they need to enforce more
| backwards compability, this can also lead to more code or more
| maintenance work.
|
| Honestly I don't see the benefit of smaller prs, except driving
| vanity scores?
|
| Like I'm not saying you should
___________________________________________________________________
(page generated 2026-04-13 23:00 UTC)