[demorro]

I continue not to understand much of the point of this. I don't recognize the git workflow the author is talking about, and neither do I see the point of stacked PRs. Commits are fine as a unit of isolating work, and rebasing to keep that neat is not difficult.

How many PR's do y'all tend to have in flight at once? I sometimes think being a native (C++) developer makes me have a different take on some of this. Maybe if I was a JS dev making quick changes with 5 PR's a day I'd care more about this.

[stouset]

Very often when writing a new feature, I have to fix a bug in another subsystem (and write tests for it), add a small capability to another subsystem, fix documentation elsewhere, and so on.

Those could be separate commits in one PR, and that’s the way I’ve historically worked. But in jj it’s trivial to make them separate branches and continue working on the merge of all of them, even if they haven’t been merged upstream yet.

The benefit is that my coworkers have absolutely trivial PRs to review, rather than one omnibus. If there’s some debate about one of them, not only can we still make progress by merging the others, but I can continue plugging away on my main feature branch while we decide on the best path forward. If one of those PRs needed a bugfix or changes, fixing them typically m requires quite literally zero VCS shuffling to incorporate into the work downstream.

My pace of and ability to work on features is no longer bottlenecked by reviews. My coworkers no longer have to review giant PRs that touch seven subsystems. I don’t have to wait until an entire feature is finished before coworkers can start merging smaller preparatory bits for it.

You can do some of this stuff in git. But it’s excruciating and so nobody does it except in rare circumstances.

[Guvante]

But that means you haven't actually done anything with the PR, it is a hypothetical thing.

Hopefully you have perfect CI coverage since you didn't bother to compile your PR even.

[stouset]

This flatly isn’t true.

Each individual PR gets tested and merged the same way they would if you’d authored them one by one in the first place.

The combination is merged in your tree well in advance of a PR ever being made. When the ancestor PRs are merged, you just pull and your descendent merge commit is rebased automatically.

At no point are you pushing untested code that you wouldn’t have pushed in a similar git workflow.

[Guvante]

I mean so it is identical to how I already do this...

If I am pushing a PR with a working combination and rebasing after upstream merges how is jj changing the flow?

[lorecore]

I totally agree. I've never understood the push back against clean "railroad tracks" (i.e. rebasing instead of merge commits). It's simple, scales nicely and gives you a lot of options. Once you start allowing merge commits in the tree, things can get messy but with a bit of discipline, it elegantly solves every version control use-case I can think of, or have encountered, including at scale.

[chadgpt3]

If you have a large PR with multiple nontrivial commits I think you should merge it so the intermediate states are the same ones that were originally tested. Otherwise you could break bisects, among other issues.

[lorecore]

You should be rebasing your PRs before you put them on main though. Test prior to doing that should not be expected to be repeatable.

[squirrellous]

Stacked PRs is mostly a way to avoid thousand- or tens-of-thousands- LOC branches, which makes each PR meaningfully reviewable. You need a good code review process for it to become useful. It’s very pleasant once you are accustomed to it.

I’ve seen successful teams that regularly do reviews of massive PRs and feel this serves them well enough. I suspect it just places a lot more trust on the developers to get the details right so reviewers only look at larger design issues.

The language of choice is not relevant. Even before AI, one can accumulate thousands of lines of c++ easily.

[ahepp]

I've also seen teams struggling to review massive PRs as a single diff, but when I've seen that it's always because they aren't structuring commits to be individually reviewable.

[surajrmal]

I work primarily in c++ and fully agree with the author. I think it makes more sense in the context of larger teams, possibly also monorepos. Review speed (both latency of feedback and how thorough your reviewers are), presubmit test runtime, flake rate, etc can lead to it taking a few days to get work submitted. In some cases you don't want to land work until you've finished a milestone of some sort. If others work on similar files to you, you will end up with several rounds of rebase conflicts to deal with too.

[ahepp]

Do stacked PRs do something to avoid rebase conflicts if two people touched the same file?

[surajrmal]

No but it's a lot simpler to rebase and address them with stacked commits.

[squirrellous]

I feel like parent was referring to a culture of shipping small changes frequently, which tends to result in stacked PRs.

[bfivyvysj]

It's useful for low velocity teams that spend too much time in review.

For everyone else it's a net loss.

I've used Gerrit years ago, I thought it was great being able to shape my diffs into stacked chunks that reviewers could effortlessly navigate in a coherent story I'm telling.

Then I joined a company that wanted you to build and ship it in the same day. Now I dread the idea of going back to week long review cycles.

Ick.