In Praise of Stacked PRs
benjamincongdon.me
In Praise of Stacked PRs
1–10 of 230 posts
Re: In Praise of Stacked PRs
#2Well this would be impossible to explain and coordinate with the team
Re: In Praise of Stacked PRs
#3We switched to using https://graphite.dev/ after yet-another huge epic that caused a mess of PRs and one PR that touched 100+ files and included dozens of semi-related changed. It's been a blessing so far.
Re: In Praise of Stacked PRs
#4Hope you like merge conflicts and rebase hell as people start to comment and ask for changes
Re: In Praise of Stacked PRs
#5I’ve played with this idea a bit. In my experience it felt like a hack to work around the fact that individual PRs took a while to get merged.
An alternative solve is to work in a way that allows PRs to be merged more quickly, ie pairing, mobbing, or prioritizing getting reviews done asap.
Re: In Praise of Stacked PRs
#6We use GitHub Enterprise where I work now. I do sometimes do stacked PRs but GHE does not make it easy. The rebasing and merge conflict resolution can be a headache although git rebase —onto helps a lot.
I previously worked somewhere that used Phabricator. Its “stacked diffs” worked great. I’d use it all the time when working on complex, multipart changes.
Re: In Praise of Stacked PRs
#7I’m going to be a little crass for a moment: people don’t know how to use their tools! Why are we even talking about “stacked PRs” and “branchless” workflows?! It’s clear the author is documenting their git learning process and that’s great, really. But I’m just surprised how pedantic people get about forcing others to use a tool in a way that caters to their own limited understanding of it. Or, even worse, caters to limitations in the 3rd party UI being used to interface with it (ye ol’ git vs GitHub problem). Learn your tool and then you can worry about the higher order things that are supported by it.
Re: In Praise of Stacked PRs
#8I've usually kept a rule that you should avoid stacking, and if you must only one level deep. The fact that you have to stack in the first place typically suggests that PRs aren't being merged fast enough. Stacking in my personal experience usually leads to merge conflict hell as changes and PR suggestions get merged underneath you.
Re: In Praise of Stacked PRs
#9One thing I wish git did (maybe it does and I don't know how?) is to be able to say that a new branch is based off an old branch (not a commit that used to be that branches head). so I can branch a single pr in progress to start the next. Then if I change the base pr in progress (say via rebase or via squashing or the like), I can easily rebase my new commits in the new pr on top of the current state of the branch.
Currently, one can just do it by never modifying the underlying "branch" (i.e. just adding new commits), but in practice that doesn't always work, as many times you have to rebase against one's master/main branch to pull in changes, which even if no conflicts, will reflow your "base" branch" changing all the commits.
TLDR: Basically, want to be able to state that branch depends on branch (which is currently commit id x) but if I rebase, use whatever the current commit id is for that branch, not whatever it was when I first made the branch.
possible? stupid idea? thoughts?
Re: In Praise of Stacked PRs
#10I’ve played with this idea a bit. In my experience it felt like a hack to work around the fact that individual PRs took a while to get merged. An alternative solve is to work in a way that allows PRs to be merged more quickly, ie pairing, mobbing, or prioritizing getting reviews done asap.
Yeah I agree. If you can merge things into a central branch quickly, it’s much better.
In my experience with this sort of process you spend quite a lot of time managing your different branches, especially once you start getting feedback and requests for changes. Then keeping everything in sync. Git helps make this quicker but it’s still effort & cognitive load.