23 ms·

GitHub Stacked PRs

• ZeWaka 6mo ago
  Seems to mainly be useful for monorepos as currently designed. Or, to replace a long-lived feature/refactor branch.
  • YesThatTom2 6mo ago
    Whatbmakes you say that? Devs use stacked PRs in small and large repos today.
    • ZeWaka 6mo ago
      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 6mo ago
    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 6mo ago
  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 6mo ago
    Who hurt you?
    • dpcx 6mo ago
      Their manager who suggested that everything be a microservice, but everything depends on each other.
      • deleted 6mo ago
        [deleted]
    • simplyluke 6mo ago
      Microservices, by the sound of the original comment
      • Arbortheus 6mo ago
        Microservices without a monorepo is hell
        • Yokohiii 6mo ago
          They've opted for critical damage.
  • whalesalad 6mo ago
    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 6mo ago
      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 6mo ago
    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 6mo ago
      > 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 6mo ago
  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 6mo ago
    Yeah, I feel like just being able to review a PR commit-by-commit with a nice interface would just suffice.
    • ezekg 6mo ago
      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 6mo ago
        How does that differ from this where you need to keep track of state and the whole change in the stack?
        • ezekg 6mo ago
          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 6mo ago
      For me that would mean avoiding tiny commits, and I wouldn't want to do that
  • jaredsohn 6mo ago
    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.
• bsimpson 6mo ago
  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 6mo ago
    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 6mo ago
      It seems partially exposed in the UI with that dropdown. There's an 'add' and 'unstack' button. Probably relies on some internal metadata.
    • ameliaquining 6mo ago
      You can in fact do this from the web UI: https://github.github.com/gh-stack/guides/ui/#creating-a-stack-from-the-ui https://github.github.com/gh-stack/guides/ui/#creating-a-sta...
      • ezekg 6mo ago
        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.
      • NooneAtAll3 6mo ago
        damn, I missed it as well presenting only cli commands in announcement wasn't a good choice
    • SamuelAdams 6mo ago
      CLI is great because now I can tell my AI agent to do it. “Fix all dependabot security issues (copy logs) and run tests to validate functionality. Create each dependency as its own stack (or commit) so that contributors may review each library update easily.” Wait 10 minutes and you’re done.
• pbrowne011 6mo ago
  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_diffs/ 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 6mo ago
  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 6mo ago
    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 6mo ago
    It's in private preview. Probably they'll put it in the main docs and such once it's open to everyone.
  • varun_ch 6mo ago
    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/ 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/ 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 6mo ago
  how is this different than viewing a PR one commit at a time?
  • simplyluke 6mo ago
    Split into individual PRs, which works better for how a lot of companies do code review.
  • Macha 6mo ago
    Each commit can be merged independently as they're reviewed.
    • Hamuko 6mo ago
      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 6mo ago
        That's possible but not mandatory. In the current UX you can only approve/submit all or none.
      • deleted 6mo ago
        [deleted]
    • CharlieDigital 6mo ago
      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 6mo ago
        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
• chao- 6mo ago
  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.
• deleted 6mo ago
  [deleted]
• adamwk 6mo ago
  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 6mo ago
    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 6mo ago
      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 6mo ago
        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.
        • dathanb82 6mo ago
          Unless you have a “every commit must build” rule, why would you review commits independently? The entire PR is the change set - what’s problematic about reviewing it as such?
          • steveklabnik 6mo ago
• jamietanna 6mo ago
  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!
• siva7 6mo ago
  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 6mo ago
    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 6mo ago
  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 6mo ago
    If you visit the webpage it gives you integration instructions for agents
  • ameliaquining 6mo ago
    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 6mo ago
      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 6mo ago
        >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.
• sailorganymede 6mo ago
  Thank goodness. It was a pain to do this manually
• fweimer 6mo ago
  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?apiVersion=2026-03-10#commit-comments https://docs.github.com/en/rest/guides/working-with-comments...). Self-stacking PRs seem redundant.
  • CharlieDigital 6mo ago
    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 6mo ago
    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 https://graphite.com/blog/introducing-frozen-branches
• bob1029 6mo ago
  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 6mo ago
    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 6mo ago
  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 6mo ago
    https://news.ycombinator.com/item?id=47614038 https://news.ycombinator.com/item?id=47614038
    • TZubiri 6mo ago
      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 6mo ago
  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 6mo ago
  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 6mo ago
    They do not no. Afaik GitHub has little to nothing that is cross repository.
• jenadine 6mo ago
  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 6mo ago
    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 6mo ago
      > 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 https://www.gerritcodereview.com/about.html
      • sunshowers 6mo ago
        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.)
• robertwt7 6mo ago
  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 6mo ago
    Yep, very happy with graphite at work.
    • heeton 6mo ago
      Same, our team has been on it for a year and it's very good.
  • acjohnson55 6mo ago
    They recently got bought by Cursor.
• K0IN 6mo ago
  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 6mo ago
  what happened to the old gerrit reviews, I loved its handling on incremental patchsets. github is primitive by comparison.
• ghighi7878 6mo ago
  What's difference between stacked PRs and merge trains in gitlab?
  • masklinn 6mo ago
    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 6mo ago
      Ahh so stacked diffs? https://docs.gitlab.com/user/project/merge_requests/stacked_diffs/ https://docs.gitlab.com/user/project/merge_requests/stacked_...
      • IshKebab 6mo ago
        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 6mo ago
  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 6mo ago
    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.
  • mattstir 6mo ago
    It appears the CLI is only half-baked so far. Given how many things they've borrowed from Graphite (a tool which adds this type of workflow), it should only be a matter of time until they add a `split` command. Graphite lets you split a large set of changes by commit or by hunk which is very handy.
• akersten 6mo ago
  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..
  • deleted 6mo ago
    [deleted]
  • xixixao 6mo ago
    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 6mo ago
      > 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).
      • skydhash 6mo ago
        Because at first your have this main <- PR A <- PR B Then you'll have main, squashed A \ \-> PR A -> PR B The tip of B is the list of changes of both A and B, while the tip of main is now the squashed version of the changes of A. Unless a branch tracks the end of A in the PR B, It looks like more you want to apply A and B on top of A again. A quick analogy to math main is X A is 3 B is 5 Before you have X + 3 + 5 which was equivalent to X + 8, but then when you squash A on on X, it looks like (X + 3) + (3 + 5) from `main`'s point of view, while from B, it should be X + (3 + 5). So you need to rebase B to remove its 3 so that it can be (X + 3) + 5. Branches only store the commits at the top. The rest is found using the parent metadata in each commits (a linked list. Squashing A does not remove its commits. It creates a new one, and the tip of `main` as its parent and set the new commit as the tip of `main`. But the list of commits in B still refer to the old tip of `main` as their ancestor and still includes the old commits of A. Which is why you can't merge the PR because it would have applies the commits of A twice.
• teaearlgraycold 6mo ago
  Wondering how all of those startups that implement this for GitHub feel right now.
  • zaps 6mo ago
    sherlocked
• mc-serious 6mo ago
  [flagged]
• sameenkarim 6mo ago
  [dead]
  • calebio 6mo ago
    Any idea if/when this would be coming to GHE? I know the release cycle is way different but curious about your thoughts.
    • sameenkarim 6mo ago
      Yeah features need to be released as GA (general availability) before they can be included in GHES. I don't have a definitive timeline, but it will likely be end of this year or early next.
  • jlebar 6mo ago
    It's a matter of taste, but I much prefer the workflow in the tool I hacked together for this, https://github.com/jlebar/git-pr-chain https://github.com/jlebar/git-pr-chain. In the tool I wrote, you have a single branch with linear history. PRs in the chain are demarcated via commit messages. You then don't need any special rebase / sync commands -- you can use regular `git rebase -i` to reorder commits or edit a commit in the middle of a stack. Literally the only special command I need is "push this branch to github as multiple PRs". Anyway I hope that alongside the branch-based you've built tool in `gh` that there will be an API that I can target.
    • sameenkarim 6mo ago
      Yup, there will be an API for stacks, just like there is one for regular PRs.
  • dastbe 6mo ago
    How does this work with a tool like jujutsu that provides native support for stacking and preferably don't have a separate tool mucking about with state?
    • 6mo ago
• atq2119 6mo ago
  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.
  • Liskni_si 6mo ago
    They haven't fixed the fork issue, the FAQ clarifies this. I suspect the target audience is squash merging corpos. Everyone else can just do normal PRs with atomic commits reviewed individually...
• scottfits 6mo ago
  cherry picking is so fragile, this is at least a step in the right direction
• jrochkind1 6mo ago
  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 6mo ago
  > 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 6mo ago
    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 6mo ago
• ChrisArchitect 6mo ago
  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 https://x.com/matthewisabel)
• WhyNotHugo 6mo ago
  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 6mo ago
    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.
    • philwelch 6mo ago
      Squashing is fine if you’re just making a mess of temporary commits as you work and you don’t want to keep any of those changes separate in master, but that’s not a useful review workflow. A lot of times I’ve built a feature in a way that decomposed naturally into e.g. two commits: one to do a preparatory refactor (which might have a lot of noisy and repetitive changes, like changing a function signature) and another to actually change the behavior. You want those changes to be separate because it makes the changes easier to review; the reviewer quickly skims the first commit, observes that it’s a mechanical refactor, and the change in behavior has its own, smaller commit without all the noise. “What if there’s feedback and you need to make changes after the code review?” Then I do the same thing I did before I posted the code review: make separate “fixup” commits and do an interactive rebase to squash them into my commits. (And yes, I do validate that the intermediate commits build cleanly.) There’s nothing you get from stacked PR’s that you don’t also get from saying “please review my feature branch commit by commit”.
• eqvinox 6mo ago
  > 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 6mo ago
  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 6mo ago
    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 6mo ago
  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 6mo ago
    > 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.
• Pxtl 6mo ago
  This feels like a workaround for git's contradictory ergonomics.
• herpdyderp 6mo ago
  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 6mo ago
    Yes! Maybe that feature will come next.
  • sameenkarim 6mo ago
    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?
    • herpdyderp 6mo ago
      > so the diff in a PR shows just the relevant changes from the specific branch That's exactly right. > you can create stacked PRs purely via the UI How? I see from the docs https://github.github.com/gh-stack/introduction/overview https://github.github.com/gh-stack/introduction/overview: > When a pull request is part of a stack How does GitHub determine if a PR is part of a stack? Is it automatically detected so that I don't need to adjust my tooling that already creates chained PRs?
      • sameenkarim 6mo ago
        When you're using the UI to open a PR, if you set the base to a branch that has an open PR there'll be an "Add to Stack" option: https://github.github.com/gh-stack/guides/ui/#step-2-create-subsequent-prs-and-add-them-to-the-stack https://github.github.com/gh-stack/guides/ui/#step-2-create-... Stacks require users to explicitly indicate that they are opening a PR that should be part of a stack.
• the_gipsy 6mo ago
  Can we merge from GitHub UI without rewriting the commit already?
• thcipriani 6mo ago
  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/ https://docs.gitlab.com/cli/stack/> [1]: <https://github.github.com/gh-stack/guides/stacked-prs/#merging-step-by-step https://github.github.com/gh-stack/guides/stacked-prs/#mergi...>
  • sameenkarim 6mo ago
    > 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 As we have it designed currently, you would have to wait for CI to pass on the bottom two and then you can merge the bottom two in one step. The top of the stack would then get rebased, which will likely trigger another CI run. Thanks for the callout - we'll update those docs to make it clear multiple PRs can be merged at once.
• zeafoamrun 6mo ago
  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 6mo ago
  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 6mo ago
    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.
    • Gigachad 6mo ago
      I've always done this by just creating new PRs that are based on the branch of the old one. Maybe this is a UI improvement?
      • steveklabnik 6mo ago
        Yes, you can do that, but there's lots of things about it that are awkward. This makes it a more first-class feature.
      • literallyroy 6mo ago
        Yeah that is a “stacked” pr. The tooling is nice especially when have a larger stack and make changes to the first branch. Update refs + push all branches, same with merging and rebasing onto main.
• fmbb 6mo ago
  > 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.
  • altano 6mo ago
    This _is_ a solution to slow reviews. Smaller reviews are faster to get in. And many small reviews take less time to review than one large review. Plus there's no review that's instant. Being able to continue working is always better.
    • fmbb 6mo ago
      I am not arguing against small PRs. Stacking PRs are not a way to make changes smaller and therefore not making reviews easier.
• lopsotronic 6mo ago
  Interesting to see how this integrates with any release flows that use a lot of tags or feature flagging.
• throwatdem12311 6mo ago
  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 6mo ago
  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.
• jwpapi 6mo ago
  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
• jen20 6mo ago
  I'm surprised no-one has commented on the "sign up for the waitlist" button being a Microsoft Office form that wants your email address and GitHub handle. This feels like an elaborate phishing attack more than a serious feature announcement.
• godzillafarts 6mo ago
  “You cannot merge a PR in the middle of the stack before the PRs below it are merged.” Huh? Some stacks need to land all at once and need to be reviewed (and merged) from the top down. It’s not uncommon, in my org at least, to review an entire stack and merge 3 into 2 and then 2 into 1 and then 1 into main. If 2 merges before 3, you just rebase 3 onto 1.
• j3g6t 6mo ago
  Super excited to give this a whirl - i've been messing with graphite's `gt` command for stacking and it's been relatively decent but I didn't love needing to bring in another tool/service/account when I only care about the stacking behaviour. Was a fun experiment but nice I can simplify back onto `gh` and `git`
  • mattstir 6mo ago
    I hope that GitHub continues copying Graphite's homework in terms of functionality, because from what I can see they don't have equivalents to `gt split`, absorb, and so on. Those can be very useful in the right contexts.
• silverwind 6mo ago
  This needs to be supported on `git` level first imho, not by a forge vendor.
  • steveklabnik 6mo ago
    What would this being supported by git mean to you?
• prakashn27 6mo ago
  Meta has something similar to this using mercurial. It was awesome.
• altano 6mo ago
  The `gh stack` CLI sounds essential for people using git, but I hope it doesn't become required, as people using things like jj/sl should be able to work with stacks. `gs submit`/`gs push` being the interface is fine, but `gs init` and `gs add` should be optional.
  • steveklabnik 6mo ago
    They confirmed below that you should be able to use this with jj just fine, just like you can already use gh to create a PR that you've authored with jj: https://news.ycombinator.com/item?id=47759426 https://news.ycombinator.com/item?id=47759426
• latentdream 6mo ago
  the Website for the release statement look soooooo bad
• solaire_oa 6mo ago
  Pretty cool to see stacks being given due attention. Also check out git-spice, which works with Gitlab (possibly others). Personally I use git-spice in place of all the conventional git commands.
• meric_ 6mo ago
  I loved using sapling / mercurial so much at work that I ended up using the sapling SCM vsc extension at home all the time for personal work. Only downside is that Phabricator is not open source so viewing it in most things sucks. Hoping now I can get a much better experience
  • mhh__ 6mo ago
    Phabricator is open source and has been for years. It has had a bumpy ride over the last few years though. Although I guess having written that I assume the internal meta one is much better
    • meric_ 6mo ago
      Huh, that's news to me. I had to do some googling and the only one I could find was by Phalicity which seems to be from a Meta employee who left and made it into a company (a la Statsig, or to some extent Graphite) Seems that company shutdown though a while ago and it got forked into Phorge, but either way I assume there's some divergence from what's internal at this point. Still I'll look into it, it does look neat and might suit my preferences still. Thanks for the headsup :)
• mhh__ 6mo ago
  1. Finally. Pull requests are consanguine and bizarre. 2. I'm not a huge fan of having to use a secondary tool that isn't formally a layer around git / like jj as opposed to github
• deleted 6mo ago
  [deleted]
• mhh__ 6mo ago
  I think the core conceptual difference between a stacked diff and PRs as we use them in open source is the following: A PR is basically a cyberspatial concept saying "I, as a dog on the internet, am asking you to accept my patches" like a mailing list - this encourages trying to see the truth in the whole. A complete feature. More code in one go because you haven't pre-agreed the work. Stacks are for the opposite social model. You have already agreed what you'll all be working on but you want to add a reviewer in a harmonious way. This gives you the option to make many small changes, and merge from the bottom
• ruined 6mo ago
  man, why is this waitlisted. this should have been a feature 10 years ago
• sbinnee 6mo ago
  Is this going to be a part of triage task? If so, it makes sense. Whether a human developer or an AI made a big PR, AI goes review it and if necessary makes stacked PRs. I don’t see any human contributors using this feature to be honest because it’s an extra work and they should have found a better way to suggest a large PR.
• zmmmmm 6mo ago
  Curious how / how well it deals with conflicts in the different branches that are part of the stack. Is there some support for managing that, or what happens when two of the branches don't rebase / merge cleanly?
  • mattstir 6mo ago
    > If a rebase conflict occurs, the operation pauses and prints the conflicted files with line numbers. Resolve the conflicts, stage with git add, and continue with --continue. To undo the entire rebase, use --abort to restore all branches to their pre-rebase state. So it tries to replay commits in the stack and will stop halfway through that individual stack (layer?) to let you fix it if there's a conflict.
• sparin9 6mo ago
  [dead]
• conor_f 6mo ago
  This just reeks to me of bad practice. Why use this as opposed to breaking your change into smaller PRs and merging them individually behind a feature flag or similar? With this, you have a marginally better UX for reviewing through the Github website, but the underlying issues are the same. The change being introduced is not sufficiently testable by itself, or it's (somehow) too tightly coupled to other parts of the UI/codebase that it can't be split. You still need to test for integration issues at every point of the stack, and some architecture issues or points of code reuse can't be seen from stacked changes like this. Not for me, but I'm glad it fits other people's workflows. I just hope it doesn't encourage people to try make poorly reasoned changes!
  • gpm 6mo ago
    When I've reached for stacked PRs (in the past, not using this feature) it's precisely because I've split my change into smaller PRs being merged individually. I've just written those smaller PRs at once, or in quick enough succession that the previous PRs weren't merged before the later ones were ready. And the later ones relied on the previous ones because that's how working on a feature works. The earlier PRs are absolutely reviewable and testable without relying on the later ones. The later ones are just treating the earlier ones as part of the codebase. I.e. everything here looks like two different PRs except the timing. An obvious example would be "implement API for a feature" and then "implement UI that uses that API". Two different PRs. The second fundamentally relies on the first.
    • scaryclam 6mo ago
      I do this as well, but there is a workflow problem to solve and that is: getting PRs merged when they need to be to continue working. It's not a simple problem to solve, we can't all just jump because someone finished some work after all. But if the PRs are OK to rubber stamp, and merge, and they're safely behind a feature flag, then it could just be as simple as letting the submitter merge without the need for an extra review. That can of course be contentious, but then we can ask "why not?" and figure out what non-human gateways need to be added to help make it possible etc. I'm finding myself increasingly interested in understanding what friction can be removed from the software review, merge and release process, without sacrificing safe, well tested, understandable code that follows good standards.
• cadamsdotcom 6mo ago
  The vibecoded frontend makes the product look like a side project. Is it?
  • steveklabnik 6mo ago
    It was announced in like November of last year, so it's certainly taken some time. The announcement was by some senior management at GitHub, so it has some degree of buy-in.
• lpeancovschi 6mo ago
  this was released about 7 years ago, no?
• fphilipe 6mo ago
  I've been doing stacked PRs for ~2 years now. Thus, I don't quite see the need for this CLI. Git has had some additions in the last few years that make this work natively – specifically the --update-refs flag[1] or the rebase.updateRefs config. Combined with `git commit --fixup`, rebase.autoStash, and rebase.autoSquash rebasing stacks becomes a breeze (as long as you work off from the tip of your stack). Add in git-absorb[2] and the heavy-lifting is taken care of. My biggest gripe with GitHub when working with stacks – and something that's not clarified in these docs – is whether fast-forward merges are possible. Its "Merge with rebase" button always rewrites the commit. They do mention that the stack needs to be rebased in order to merge it. My workaround has been `git merge --ff-only top-branch-of-stack` to merge the entire stack locally into main (or anything in between actually) and then push. GitHub neatly recognizes that each PR in the stack is now in main and marks them all as merged. If there are subsequent PRs that weren't merged it updates the base branch. Having said that, it's great to see GitHub getting a proper UI for this. It's also great that it understands the intent that branch B that goes on top of branch A is a stack and thus CI runs against. I just hope that it's not mandatory to use their CLI in order to create stacks. They do cover this briefly in the FAQ[3], but it might be necessary to use `gh stack init --adopt branch-a branch-b branch-c`. On the other hand, if that removes the need to manually create the N PRs for my stack, that's nice. [1]: https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---update-refs https://git-scm.com/docs/git-rebase#Documentation/git-rebase... [2]: https://github.com/tummychow/git-absorb https://github.com/tummychow/git-absorb [3]: https://github.github.com/gh-stack/faq/#will-this-work-with-a-different-tool-for-stacking https://github.github.com/gh-stack/faq/#will-this-work-with-...
  • locknitpicker 6mo ago
    > Git has had some additions in the last few years that make this work natively – specifically the --update-refs flag[1] or the rebase.updateRefs config. Combined with `git commit --fixup`, rebase.autoStash, and rebase.autoSquash rebasing stacks becomes a breeze (as long as you work off from the tip of your stack). Add in git-absorb[2] and the heavy-lifting is taken care of. ...or you don't bother with all that and simply do: - gh stack init - gh stack push - gh stack submit
• rs545837 6mo ago
  This is awesome honestly, Stacked PRs are one of those features that feels obvious in hindsight. Breaking a n-line PR into 3 focused layers where each one is independently reviewable is a huge win for both the author and reviewer. The native GitHub UI with the stack navigator is the right call too, and there's no reason this should require a third-party tool. One thing I keep thinking about in this same direction: even within a single layer of a stack, line-level diffs are still noisy. You rename a function and update x call sites, the diff shows y changed lines. A reviewer has to mentally reconstruct "oh this is just a rename" from raw red/green text. Semantic diffing (showing which functions, classes, methods were added/modified/deleted/moved) would pair really well with stacks. Each layer of the stack becomes even easier to review when the diff tells you "modified function X, added function Y" instead of just showing changed lines. I've been researching something in this direction, https://ataraxy-labs.github.io/sem/ https://ataraxy-labs.github.io/sem/. It does entity-level diffs, blame, and impact analysis. Would love to see forges like GitHub move in this direction natively. Stacked PRs solve the too much at once problem. Semantic diffs solve the "what actually changed" problem. Together they'd make code review dramatically better.
• MASNeo 6mo ago
  Very curious about this as especially with more use of AI in the development process I have seen PR size has increased. So looking forward to general availability.
• boomlinde 6mo ago
  IME the github workflow promotes bad commit hygiene by making squashing or rebasing as-is an either-or choice in the web GUI. This will help some since you can more easily split PRs into units that make sense to squash at the end, but it still seems like not doing this on a per-commit basis is a disadvantage compared to Gerrit. With Gerrit I can use all the built-in Git rebase/squash/fixup tools to manage the commit stack and push everything in one go. I don't think there's a nearly as convenient a way to work with stacked branches in Git.
• baalimago 6mo ago
  Sounds like a merge-conflict nightmare
• srvaroa 6mo ago
  This feature is 10 years late
• jollife 6mo ago
  [dead]
• jiusanzhou 6mo ago
  [dead]
• AJRF 6mo ago
  I have never got a good answer to "can't you just make smaller PRs". This is convoluted tooling (needs its own CLI) for something you could achieve with just learning how git works.
  • hambes 6mo ago
    I agree that a `gh stack` command is not needed, but this feels to me like just a better UI feature for a good git workflow. It literally is about making multiple smaller PRs that build on top of each other.
    • scaryclam 6mo ago
      The question is, why are you not just merging them into main as you go? It's a bit of a smell when you "need" to merge branches into branches. It shows a lack of safety and ease in deployments, which is the real problem to solve IMO.
      • dontlikeyoueith 6mo ago
        Because sometimes there are changes that need to land as all or nothing.
        • ninkendo 6mo ago
          Stacked PR’s… don’t do that though? They’re just PR’s. You can merge just the first one in the stack, and now it’s not “all or nothing”. Reading the docs, I don’t see a way to signal that the PR’s must all merge together. Because the most natural way of saying “these changes need to land atomically” is called a branch, and landing it atomically is called a “merge”. But I guess GH’s UI sucks for reviewing large changes, so we’re stuck having to make each change independently mergeable and pass tests (likely disabling dead-code lints, etc) just to work around this limitation. Sigh. At least when I actually do want changes to be mergeable in a stack, I now have a better UX for having folks review them.
      • hambes 6mo ago
• nonoesp 6mo ago
  First thing that came to mind was git butler.
• metafeather 6mo ago
  I've been using `git town`[1] for years to managed stacked PR's alone with Github PR's[2] and juniors I have introduced it to have really found it a helpful mental model when developing features. I hope the Gitub CLI will include syncing[3] 'stacks' locally with upstream in a similar way. [1]: https://www.git-town.com/stacked-changes.html https://www.git-town.com/stacked-changes.html [2]: https://github.com/marketplace/actions/git-town-github-action https://github.com/marketplace/actions/git-town-github-actio... [3]: https://www.git-town.com/commands/sync.html https://www.git-town.com/commands/sync.html
• netheril96 6mo ago
  Does this work from a fork? That is, can I file a stacked PR to a project not owned by me, by creating branches in my forked project? Previously I asked AI about how to contribute stacked PR, it told me that I can only do it when I have push privileges to the repo, not from a fork, and the doc here is ambiguous. ---- OK, I found this from official docs, so this feature is now quite useless to me: > Can stacks be created across forks? > No, Stacked PRs currently require all branches to be in the same repository. Cross-fork stacks are not supported.
• elAhmo 6mo ago
  Hah, first time seeing github.github.com
• vedant_awasthi 6mo ago
  This is useful. Managing dependencies across PRs has always been tricky — nice to see better workflows evolving.
• vedant_awasthi 6mo ago
  Interesting direction. Curious how this compares with traditional transformer-based approaches in real use cases.
• sajithdilshan 6mo ago
  I already do this using git branched. Whenever I have features that depends on one another I create a feature branch and then stack branches on top of each other for individual feature so it's easy for the reviewer to go through the code and and also keep the PR size quite small. Also this gives me freedom to push more than one commit for each branch to fix things. The only annoying part is that I have to keep on merging the base branch to the feature branch constantly to keep it up-to date. If Github can provide a feature to do that automatically, then that would be perfect. Other than that, I don't see any advantage on this stacked PR approach they are proposing.
• jamesfisher 6mo ago
  Reminder that if your agent can create PRs then it can merge them too: https://github.com/orgs/community/discussions/182732 https://github.com/orgs/community/discussions/182732
• balamatom 6mo ago
  Oh cool, soon people will stop being incapable of working with me.
• samsin 6mo ago
  'Large pull requests are hard to review' is a good reason to keep PRs small, but small PRs also encourage continuous integration/delivery/deployment. Stacked PRs sound like they encourage long-lived feature branches instead.
  • dontlikeyoueith 6mo ago
    Depends on what you consider long-lived. I typically generate stacks of 3-5 PRs in 1-2 days now (in a gen-AI world).
• nathas 6mo ago
  Meanwhile, you still can't do fast-forward merges in GitHub :clown: https://github.com/orgs/community/discussions/4618 https://github.com/orgs/community/discussions/4618 And it doesn't even rebase and merge correctly with fast-forward if there it's a clean set of commits! https://github.com/orgs/community/discussions/5524 https://github.com/orgs/community/discussions/5524
  • deleted 6mo ago
    [deleted]
  • charles_f 6mo ago
    [flagged]
    • surajrmal 6mo ago
      Right. Just use directly.
    • tele_ski 6mo ago
      It is a table stakes missing feature.. for a long time. Clown seems appropriate, every project I've worked on in github we end up copying a github yml action to allow us to do this with one comment '/fast-forward', just is silly at this point that github doesn't natively support it.
• sylware 6mo ago
  microsoft broke nearly all classic web support (noscript/basic (x)html). Since I can still login, is there a web API (using CURL and some identifying session token I could retrieve from my login) I could use to actually do "something". For instance, be involved in the issues of some project? (for me, that would be mostly valve stuff on linux based OSes) Any pointers?
• Liskni_si 6mo ago
  It's awesome that they're adding a UI for stacked branches¹! The UX of the CLI tool seems weird, though. Why do I need to explicitly create and add branches to the stack if all I really want is to open PRs from my commits? Here's the workflow that I built for myself instead: ∙ `git checkout -b feature-branch-xyz` ∙ make a few commits, perhaps some fixups, rebase, whatever ∙ start tig, look at the history, decide at which points I want to break the branch into stacked PRs, and mark those points using shift-s (which calls my own `git gh-stack branch create $commit` and creates a specially named branch there) ∙ `git gh-stack sync` — collects all the specially named branches, builds a graph of how they're stacked on one another, pushes them, opens stacked PRs GitHub has had some "support" for stacked PRs for a while, so merging the first one to main will automatically change the target branch of the second to main. If I need to change anything, I can just `git rebase --interactive --update-refs`, amend commits, split commits, rearrange commits, and then running `git gh-stack sync` will update the PRs for me. If I split a commit in the middle and shift-s to mark it, it will open an extra PR and restack everything to update the order. Furthermore, the "PR stack" doesn't actually need to be a stack (linear chain), it can be a tree. If I know that some commits are independent of the rest, I don't need to create a separate stack, I just create another local branch, mark PR-ready commits with shift-s, and `git gh-stack sync` will do the right thing. If I need to rebase the whole tree on top of current main, then `git rebase -i --rebase-merges --update-refs` does the job. I guess what I'm saying is that as someone who's been using git since its inception, it feels much more natural to just do everything in git, and then have a single command that pushes my work to GitHub. And I think this might work even better with jujutsu — just point `git gh-stack sync` at the branches jj makes and it'll make a stack/tree of PRs out of them. :-) https://github.com/liskin/dotfiles/blob/home/bin/git-gh-stack https://github.com/liskin/dotfiles/blob/home/bin/git-gh-stac... if anyone's curious. It's just a few hundred lines of code. Building the graph is done by `git log --simplify-by-decoration`. Opening PRs is shelled out to `gh pr create`. ¹) I mean, I'd much rather they added a UI for reviewing PRs commit-by-commit, with the option to approve/request-changes on each, and the possibility to merge the first few approved ones while continuing work on the rest… But in a world of almost every $dayjob insisting on squash-merging, a UI for stacked PRs is a total game changer, positively.
• iknownthing 6mo ago
  That page looks vaguely AI generated
• choi0330 6mo ago
  Wait. I built pilegit, Stacked PR solution. All in all, pilegit works with Github, Gitlab, Phabricator, Gitea, and custom. How about https://github.com/hokwangchoi/pilegit https://github.com/hokwangchoi/pilegit?
• boisterousness 6mo ago
  Stacked Git (StGit) [1] is a git CLI add-on for working with stacked commits in your local repo. Why are stacked commits useful? Multiple patches can be developed concurrently and efficiently, with each patch focused on a single concern, for a clean Git commit history and improved productivity. The tutorial [2] says: > One common use of StGit is to “polish” a Git branch before publishing it to another public repository. The kinds of polish that StGit can help with include: Complete and correct commit messages. Each patch limited to one coherent topic. Each patch standing on its own: passing tests, etc. Considerate patch (commit) order > Careful curation of Git commit history, as enabled by StGit, can be of high value to those reviewing pull requests or trying to understand why or how code came to be the way it is. ... > As a concrete example, consider a situation where several Git commits have been made in a repository with commit messages such as: “Improve the snarfle cache” “Remove debug printout” “New snarfle cache test” “Oops, spell function name correctly” “Fix documentation error” “More snarfle cache” > While the above may be the “true” history of commits to the repository, it may not be the history that is most helpful to code reviewers or the developer who needs to understand what happened in this area of the code six months after the fact. Using StGit, this history can be revised to be higher quality and higher value. Originally written in Python (2005, pre-GitHub) by Catalin Marinas, the current version is in Rust. StGit is free and open source [3]. It was inspired by Quilt [4], an earlier system credited to Andrew Morton and Andreas Grünbacher. [1] https://stacked-git.github.io/ https://stacked-git.github.io/ [2] https://stacked-git.github.io/guides/tutorial/#development-branch-workflow https://stacked-git.github.io/guides/tutorial/#development-b... [3] https://github.com/stacked-git/stgit/ https://github.com/stacked-git/stgit/ [4] https://en.wikipedia.org/wiki/Quilt_(software) https://en.wikipedia.org/wiki/Quilt_(software)
• hackerboomer 6mo ago
  yo what is this about chat I'm in class chill
• hackerboomer 6mo ago
  what happen to everyone and why is chat so dead
• hackerboomer 6mo ago
  everyone just stop texting 7 days ago which is kinda warid
• hackerboomer 6mo ago
  does anyone have any games for school you should send it to me