we have been stacking on tangled.org for a while now, you can see a few examples of stacks we have made here: https://tangled.org/tangled.org/core/pulls?state=merged&q=st...

for example, this stack adds a search bar: https://tangled.org/tangled.org/core/pulls/1287

- the first PR in the stack creates a search index.

- the second one adds a search API handler.

- the last few do the UI.

these are all related. you are right that you can do this by breaking a change into commits, and effectively that is what i do with jujutsu. when i submit my commits to the UI, they form a PR stack. the commits are individually reviewable and updatable in this stacking model.

gh's model is inherently different in that they want you to create a new branch for every new change, which can be quite a nuisance.

have written more about the model here: https://blog.tangled.org/stacking/

▲

ninkendo 2 hours ago | parent [-]

> - the first PR in the stack creates a search index.

> - the second one adds a search API handler.

> - the last few do the UI.

So you're saying you're going to merge (and continuously integrate, perhaps to production) a dangling, unused search index, consuming resources with no code using it, just to make your review process easier?

It's very depressing that review UX is so abysmal that you have to merge features before they're done just to un-fuck it.

Why can't the change still be a big branch that is either all merged or not... and people can review it in chunks? Why do we require that the unit of integration equals the unit of review?

The perverse logic always goes something like this:

"This PR is too big, break it up into several"

Why?

"It's easier to review small, focused changes"

Why can't we do that in one PR?

"Because... well, you see GitHub's UI makes it really hard to ..."

And that ends up being the root-cause answer. I should be able to make a 10,000 line change in a single commit if I want, and reviewers should be able to view subsets of it however they want: A thread of discussion for the diffs within the `backend` folder. A thread of discussion for the diffs within the `frontend` folder, etc etc. Or at the very least I should be able to make a single branch with multiple commits based on topic (and under no obligation for any of them to even compile, let alone be merge-able) and it should feel natural to review each commit independently. None of this should require me to contort the change into allowing integration partially-completed work, just to allow the review UX to be manageable.

	▲	matharmin an hour ago \| parent [-]
		This is not just about the UI, it's about the mental model and management of the changes. Just covering the review process: Yes, you can structure your PR into 3 commits to be reviewed separately. I occasionally structure my PRs like this - it does help in some cases. But if those separate parts are large, you really want more structure around it than just a commit. For example, let's say you have parts A, B and C, with B depending on A, and C depending on B. 1. I may want to open a PR for A while still working on B. Someone may review A soon, in which case I can merge immediately. Or perhaps it will only be reviewed after I finished C, in which case I'll use a stacked PR. 2. The PR(s) may need follow up changes after initial review. By using stacked PRs instead of just separate commits, I can add more commits to the individual PRs. That makes it clear what parts those commits are relevant to, and makes it easy to re-review the individual parts with updated changes. Separate commits don't give you that. Stacked PRs is not a workflow I'd use often, but there are cases where it's a valuable tool. Then apart from the review process, there are lots of advantages to keeping changes small. Typically, the larger a change, the longer it lives in a separate branch. That gives more time for merge conflicts to build up. That gives more time for underlying assumptions to change. That makes it more difficult to keep a mental map of all the changes that will be merged. There are also advantages to deploying small changes at a time, that I won't go into here. But the parent's process of potentially merging and deploying the search index first makes a lot of sense. The extra overhead of managing the index while it's "unused" for a couple of days is not going to hurt you. It allows early testing of the index maintenance in production, seeing the performance overhead and other effects. If there's an issue, it's easy to revert without affecting users. The overall point is that as features become large, the entire lifecycle becomes easier to manage if you can split it into smaller parts. Sometimes the smaller parts may be user-visible, sometimes not. For features developed in a day or two, there's no need to split it further. But if it will span multiple weeks, in a project with many other developers working on, then splitting into smaller changes helps a lot. Stacked PRs is not some magical solution here, but it is one tool that helps manage this.