{"slug": "neat-trick-to-make-big-prs-readable-reslicing-them-into-small-commits", "title": "Neat trick to make big PRs readable: reslicing them into small commits", "summary": "A developer published a reusable AI skill called \"restack-pr-commits\" that reorganizes a large pull request into roughly 20 individually reviewable commits while keeping the fully stacked result character-for-character identical to the original PR. The author, who first saw the commit-slicing technique about seven years ago as a Tech Lead at Vena Solutions, used AI to reslice a +4k/-1k changeset touching 72 files, a size he now encounters regularly. The skill checks out the PR branch, creates a backup branch, and requires each commit to be reviewable rather than independently compilable or test-passing.", "body_md": "It’s pretty hard to review a PR with a +4k/-1k changeset that touches 72 files. PRs like that used to be rare, maybe if there was a large refactor or an upgrade that had to go in all at once. But now I run into them regularly.\n\nLast week, when AI wrote two of those for me and I had to review them, I decided to try a new trick.\n\nWell, the trick is actually old; I first saw it about seven years ago when I started working as a Tech Lead at Vena Solutions. Back then, our VP of Architecture really liked refactoring and cleanup, which often produced large PRs. To make those PRs palatable to us, he organized them into neat, very focused individual commits with one specific change in each commit, something like this:\n\n```\nf8ee9aa   Rename class BadlyNamedClass to BetterNamedClass\n18c240f   Simplify logic in BetterNamedClass.SomeMethod()\n1a4acf0   Update tests for BetterNamedClass.SomeMethod()\n8b10bc0   Clean up unused imports\n          ...(etc)...\n```\n\nSome commits had a lot of lines changed, but it was the same change on each line (e.g. rename `SomeThing` to `OtherThing`). Other commits had a specific narrow focus, like a tweak to a complex algorithm. Each individual commit didn’t have to be compilable or pass tests by itself; it just had to tell the next chapter in the overall story of what the PR was doing.\n\n## You can get AI to reslice an existing PR\n\nThat’s the new trick I tried: getting the AI to do that to a pre-existing PR.\n\nI would have never done this by hand myself. But AI has infinite patience (well, as long as the tokens last), and it had no problem tearing apart all 4k lines of code and carefully piecing them together into 20-ish commits. It wasn’t perfect, but it was good enough that reviewing was a lot easier.\n\nSo then I turned it into a skill (below); after using it on several more PRs, I think from now on I’ll be doing it every time just so that I can read the PRs myself.\n\n```\n---\nname: restack-pr-commits\ndescription: 'Reorganizes the PR as a series of easily reviewable commits.'\nargument-hint: 'for pull request <PR URL>'\n---\n\n## Overview\n\nThe goal of this skill is to turn a large, hard-to-review \nPR into a series of commits that are each individually easy \nto review. The commits, once fully stacked, must match the \noriginal PR character-for-character. \n\nEach commit is \"easily reviewable\" if it introduces a \nrelatively straightforward change. It can be a commit \naffecting a large number of lines that does something simple \n(e.g. rename a variable or clean up unused imports), \nor a commit that adds a specific tricky concept in one \nfile, or something in between. Generally, new tests \nshould be added separately from the newly added code, \nbut a change to functionality can have a single commit \nspanning both the main code and the tests.\n\nEach individual commit doesn't need to pass the build or \nthe tests; the primary criterion is reviewability.\n\n## Steps\n\nYou should have been provided a PR to work on. If you \nhaven't, stop and ask for it.\n\nMake sure that you're clear on which branch the commits \nare based on. We'll call this branch the \"base branch\".\nThis would usually be the repo's main branch (called \n`master`, `develop`, `dev`, or `main` - this depends on \nthe repo) but it may not always be the case. If it's \nunclear what the base branch is, stop and ask.\n\n1. Check out the PR's branch locally. Make sure you're\n   on the latest version of it. Once done, your \n   current branch should be the PR's branch. We'll\n   call it `{current-branch}` from now on. If during \n   this step you cannot use `git` or `gh`, stop and let \n   the user know, as you won't be able to proceed further.\n2. Make a backup of the current branch.\n    - Do: \n        - `git checkout -b {current-branch}-backup`\n        - `git checkout {current-branch}`\n        So that you end up with the backup of the current \n        branch, but you'll still be working on the current \n        branch. DO NOT drop the backup branch; we will \n        leave it forever as a backup, so don't clean it up.\n3. Come up with the commit breakdown.\n    - Review the contents of the PR, the PR description, \n      and any relevant documentation to fully understand \n      the changes.\n    - Come up with several distinct ideas for how to \n      split up the PR into easy-to-review commits.\n    - Come up with the criteria to figure out which of \n      the choices is best.\n    - Review each of the proposals for the split. Evaluate \n      them against your criteria, critique them, and rank \n      them against each other.\n    - Based on your critiques, update each of the options \n      for the split.\n    - Critique and rank these options again and come up \n      with the final ranking.\n    - Come up with the final recommendation for how to \n      split the PR into commits. The final recommendation \n      may be any combination of the proposed \n      recommendations based on your analysis.\n4. Figure out a strategy you'll use for verifying that \n   the final result matches the current PR \n   character-for-character. Make appropriate preparations \n   as necessary.\n5. Rebuild the PR as a series of commits on top of the \n   base branch as per your proposal. After each commit, \n   verify that the commit has added exactly what you \n   think it should have added and that there's nothing \n   missing and no copying errors. If there are any issues, \n   amend the commit as needed. Each individual commit\n   doesn't need to pass the build or the tests, so don't \n   rerun those between the commits. \n6. Verification: when done, verify that the final \n   result matches the current PR \n   character-for-character. If not, fix any commits \n   as needed. \n7. Rerun the build and the tests as needed. \n8. Force-push the changes to the origin so that the \n   PR now looks like a series of new commits.\n\nDo not clean up the backup branch; we may need it \nlater if there were any issues.\n```\n\n## But what about stacked PRs?\n\nIf you aren’t familiar with stacked PRs, [this GitHub page](https://docs.github.com/en/pull-requests/get-started/about-stacked-prs) gives a decent overview.\n\nThey’re certainly an option, but I find that before starting the implementation, it’s not always clear which PR should be the base PR, and sometimes after a lot of fixes and follow-up tweaks, the stack needs to get reorganized a lot, which is annoying to do when you’re dealing with PRs instead of commits.\n\nAnd it’s a lot more practical to reslice a 4k LOC PR into 20 commits rather than 20 stacked PRs.", "url": "https://wpnews.pro/news/neat-trick-to-make-big-prs-readable-reslicing-them-into-small-commits", "canonical_source": "https://www.i-kh.net/p/neat-trick-to-make-big-prs-readable", "published_at": "2026-10-08 12:31:21+00:00", "updated_at": "2026-10-08 12:47:30.888318+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["Vena Solutions", "restack-pr-commits", "GitHub"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/neat-trick-to-make-big-prs-readable-reslicing-them-into-small-commits", "markdown": "https://wpnews.pro/news/neat-trick-to-make-big-prs-readable-reslicing-them-into-small-commits.md", "text": "https://wpnews.pro/news/neat-trick-to-make-big-prs-readable-reslicing-them-into-small-commits.txt", "jsonld": "https://wpnews.pro/news/neat-trick-to-make-big-prs-readable-reslicing-them-into-small-commits.jsonld"}}