[Insimwytim]

I feel like many people (and industry in general) complicate things unnecessary.

  Stacked pull requests break large changes into small, reviewable pull requests. 

That's how pull requests are supposed to be, no? If yours aren't that - you ought to rewrite them.

  With stacks, you can independently review and check each pull request, then merge everything together in one click.

Why would I want to do that instead merging (and deploying/testing) separately, which gives me more reliability?

  No more opening a single large pull request that takes forever to review, or splitting work across multiple branches you have to keep manually rebasing.

Well, it doesn't seem like a simplification over dreaded "manual rebasing". And the target branch still moves, doesn't it? So, how are you "saved" from rebasing?

It's like responsibility is shifted from the author to the tool. That has been tried before, and every time it seem to consistently produce a similarly shaped mess in a different area of a process, but with an added bonus of the tool's own problems and restrictions.

[kazinator]

I also don't get it.

> With stacks, you can independently review and check each pull request, then merge everything together in one click.

Consider:

"With pull requests, you can independently review and check each commit inside the pull request, and then merge the entire pull request in one click."

Pull requests are stacked commits. This does not have to recurse; you don't need stacked pull requests, not to mention stacked pull request stacks.

A commit can already contain changes to multiple files. In many cases, even a complex change can be just one commit. A sequence of multiple commits handles all the remaining cases.

Stacked PRs sound like a use case for someone who never wants a PR to be a container for multiple commits, such that if a unit of work is best done as three commits, they want them in separate PRs. Oh, but now they are not related together, the way a stack of commits is related under one PR, so we need a meta-PR to contain PRs or something.

This could be a consequence of commits being sort of second class citizens in the GitHub UI compared to PRs. If you want a commit to be treated as PR, on the same level, you must create a PR with nothing but that commit. So then, what would have been a single PR with four commits that you could merge with one click is now four PRs. Which you want to be able to merge them with one click.

[masklinn]

> With pull requests, you can independently review and check each commit inside the pull request, and then merge the entire pull request in one click

Except you can’t really do that on GitHub, the “unit if review” is the PR so reviewing commits is adhoc, inconsistent, and awkward, and tracking their changes as they get fixed up is a pain. “Splatting” that as PRs is not the nicest way to do it green field, but it’s an evolution that makes sense in GitHub’s model.

[kazinator]

Right; so maybe that's the thing to fix.

[tao_oat]

Here's a common flow where I find stacked PRs are useful:

- I want to build feature X

- Ah, but it would work better if I refactored the module first

- I refactor then build feature X

- There's then some additional (and optional) cleanup work

As a reviewer I wouldn't want to see all this in a single PR, and the changes depend on each other so I can't open multiple independent PRs. Manual rebasing is fine but navigating the GitHub UI is then annoying, I have to mentally keep track of where I am in the stack.

[mchristen]

Those could just be individual commits on a branch. Why does it need to be a stacked PR? That concept really only exists within the interfaces of these kinds of tools.

[andrewaylett]

They don't. But reviewing individual commits in the GitHub UI is hard.

A set of stacked PRs is exactly the same as a line of commits. The only difference is the UI, but the UI is the important bit here because lack of UI is what's stopping folk from doing that today.

Even when I've developed my changes as a stack of commits, I'll feed them to my team one commit (and one PR) at a time so they're easier to review — and I discovered that GitHub had turned on stacked commits UI because for one particular project I'd manually created a set of PRs in advance (with the right bases) and GitHub offered to create a stack out of them.

[4lx87]

> They don't. But reviewing individual commits in the GitHub UI is hard.

So instead of solving that problem, GitHub developed tooling around a workaround for that problem (targeting a PR at another branch that also has a PR).

Expanding reviews to allow per-commit reviews avoids the need for managing additional branches and all the headache that comes with it.

[andrewaylett]

Indeed. But lots of people have never even heard of Gerrit :P.

And the implementation feels very much like it sits in the UI layer, rather than further down the stack.

I'm not trying to claim stacking PRs in this way is the best way (it's not). But it does add an extra affordance for those who want it without burdening those who don't with the need to understand why someone would prefer it.

And there are also plenty of ways that people have been working around GitHub's (and to a lesser extent, git's) lack of tooling for working on changes in this way. I'm sure they have customers clamouring for the feature; whether they'll be happy with what they get remains to be seen.

(Very happy jujutsu user here, my tooling makes it really easy to create stacked commits with a stable identifier that maps really easily to branches and then onwards to running `gh stack`, but what GitHub have delivered is definitely still lacking)

[ghthor]

I’m a pretty clean committee. About every graphite stack I’ve worked on for the past 2years has been single commit per PR. The tooling managing all the rebasing and PR bases is great.

[atq2119]

The sad fact of life is that too many developers are used to pushing PRs with unprincipled commits, and relying on squash merges.

The approach that GitHub chose can show those people almost immediate benefits, which is surely the better path towards adoption than trying to reeducate everyone to adopt a development flow based on clean rebases.

And for those of us who do prefer clean rebases, the thing they built is still useful.

A bunch of details aside, the major conceptual thing that the email based flow has which is still missing in GitHub's data model is the ability to have a discussion on the stack as a whole.

[cube00]

> The sad fact of life is that too many developers are used to pushing PRs with unprincipled commits, and relying on squash merges.

We couldn't organise our commits once the PR review started because reviewers would complain they couldn't easily determine what had changed between rounds of reviews.

If we tried to organise them after review then approvals would be stripped so squash was the only way we could keep the main line history reasonably tidy as you can keep the approvals if GitHub does the squash via the UI.

[esafak]

They could but they don't belong together. A PR should be about one thing. Refactoring one module for another's sake should be done in another PR. If not for reviewing, for revertability, and future debuggability.

[tao_oat]

Yeah, I think it's largely a UI issue! I really want a UI that lets me review distinct changes that are dependent on each other, and handle comments/changes neatly within that structure. I've found GitHub quite lacking there historically.

Also, if you're the mchristen I know, then I think we've had this discussion before haha! Hope you're well :)

[mchristen]

Hah, indeed. I only know one Tao :) Some things never change I suppose

[kazinator]

I certainly don't want to see that in a one commit. A PR has one more more commits, though.

The commits in a PR are already a stack of patches, and so PRs are already "stacked" as they are.

If feature X depends on the refactoring (cannot be rebased on the un-refactored upstream), it's part of the change; you can't just merge the feature and not the refactoring.

If the two are separable that way then, sure, it makes sense to ask for them to be separate PRs.

[hypendev]

Why isnt refactor in its separate PR? Every developer with an ounce of thought would tell youn to:

>Do PR refactoring module A >Do PR with feature X + cleanup >Maybe PR with additional work if bigger

[tao_oat]

I think we're saying the same thing, that's how I use stacked PRs.

[Insimwytim]

I do that too. I do introduce changes in separate PRs. They could be related to the same problem and referenced accordingly.

  and the changes depend on each other so I can't open multiple independent PRs

Why? Is it a technical restriction? Tightly coupled architecture is not the best solution anyway.

[malcolmgreaves]

A refactor and then a feature implemented on that refactor is tightly coupled by definition. It would not make sense to implement the feature and refactor independently, because you’d be wasting time implementing a feature that you would have to refactor again.

[pyth0]

This is literally the point of stacked PRs. You implement the refactor in branch A, then branch B is created on top of that so you can implement your feature. Then you make separate PRs, one for merging branch A into main, and another for merging branch B into A. The GitHub feature just provides a nicer UX when interacting with such PRs by clearly showing dependency and allowing you to merge a stack together.

[mahmouds]

This. I don't even GitHub-style pull requests. A mature, big and complex project like the Linux kernel is still being (happily) developed using small email-based patches. I really appreciate the decision made by Drew Devault in SourceHut <https://man.sr.ht/~ireas/guides/contributing.md> to follow this effective yet simple way of managing contributions. GH PRs encourage a bad habit of making large, complex and unrelated changes in a single PR (or even one commit). Mainly bad because it makes the review process overwhelming and inefficient.

[mrkeen]

I don't mind rebasing, so that's not really an issue.

The problem I sometimes have is when I queue up 4 or 5 PRs in the afternoon and expect someone to take a look in the morning.

The diff of A into master looks OK, but then the diff of B looks like AB, and the diff of C looks like ABC - each PR has changes that will have already been merged once earlier PRs have been accepted.

My way around it was to raise E as a PR into D, raise D as a PR into C, etc. Then once approved, I change their destinations back to master for the actual merges.

It really confuses reviewers though, even though it's meant to make it so they only see the appropriate changes.

[ghthor]

This is stacking but with getting no help from the platform tooling or UI. Your ready and stacking feels great. I’m a 2 year user of graphite and it really makes work a lot more fun not managing all the PR, bases, etc. make good commits, split each into a branch:PR, record faster, async progress while getting reviews, etc. it’s good stuff