[sunshowers]

I apologize for being somewhat direct but what prior art did you engage with? Why are you making people create a branch for each change in a stack? Why do developers have to create new commits when iterating on the PR? Where is the proper support for interdiffs? What about change IDs?

The fundamental issue with GitHub -- really, its original sin -- is that the review model is wrong. It encourages a new commit + merge workflow, which is simply worse than an amend + rebase workflow. Basically every other review system in existence -- Gerrit, Phabricator, what Google and Meta have internally, the LKML -- works around stacks where people amend and rebase their commits when changing them. All of these have some notion of a "diff", with "versions" that are each tracked separately, and the ability in the review tool to do diffs between those versions. My hope with stacked PRs was that for once GitHub would use this as an opportunity to modernize its review system and bring it in line with all of these other ones. But sadly that just doesn't seem like it's on the cards.

[Anon1096]

Github salaries can't afford devs from Google and Meta who have seen the bliss of a well oiled massive monorepo change management system and forge.

[crakhamster01]

Having also worked with the tools you mentioned, is using commits in-place of "versions" + squash merging all that different?

  1. Adding commits means reviewers can easily diff changes to the PR
  2. Squash merging preserves only 1 commit per PR ends up on trunk

[sunshowers]

I use `spr` which translates a local rebase + amend workflow into a GH-friendly new-commit + merge on the remote (which is then squashed). They are kind of equivalent from a 30k foot view but the dev experience when working with source control locally is dramatically different. And in particular I regularly have stacks of dozens of commits in flight -- if each commit were a series of commits then I would probably lose it.

[Game_Ender]

About 4.5 years ago they had an internal prototype for changing PRs to be diff based instead of commit based. I even saw some screenshots of it! I assume the change was too drastic, or had too many corner cases so it was dropped. There is a lot of complexity in there system around PR status checks that I could see possibly having issues.

The optimistic person in me thinks now that have a major feature which rebases and amends all the time, they will dust that off and get it shipped. Like you said, is shows a fundamental miss-understanding of the problem.

[ptx]

Doesn't GitHub do this already? If I force push the PR branch, the PR shows a message about this with a link to diff it against the previous version.

[Groxx]

Mostly. You can't do "show me this commit in the stack before and after the force push" though iirc. And you can't comment on the derived diff, even though that's what you'll be reading during re-review to see what changed.

GitHub constantly feels like features get requested with a one-sentence description, and then people who have never used any other major code review systems go build it without any further assistance or feedback, and eventually it just escapes containment and nobody tells the authors that there's a gigantic pile of bug feedback threads until almost a year later. Ten things get fixed, then another feature breaks out and focus shifts.

[sunshowers]

The seeming lack of engagement with prior art is so frustrating.

[ahoka]

I think it's a very Microsoft thing. It's a parallel evolution of software branching from the microcomputer era.

[sunshowers]

GitHub has a chance to get a generation of developers on to better coding practices. LLMs make it more feasible than ever to maintain high-quality patch series/stacked diffs — they can take care of all the mundane things like rebase conflicts for you. If I were in charge I would take this responsibility very seriously.

I guess the next best thing would be to port spr to this. (Probably time to start looking at this to be honest!) This makes me quite sad.

[Degorath]

Not sure if it makes you feel better, but it seems there's at least a few startups trying to get a jujutsu-native forge going, by people who have seen and used the way Google's (and other big tech's) systems work.

[Groxx]

It was definitely also the case before Microsoft, but I can't imagine it has improved since the acquisition. I try to avoid the site nowadays, it's randomly extremely slow and I would much rather spend my energy elsewhere anyway.

[Too]

This emphasizes the problem even more. Only one out of ten people use the force push approach, most others add commits to the PR.

Allowing two different workflows – even within the same project – just shows the lack of strategy for how this should work.

Re-educating when and when not force-push is a holy sin is also a barrier to alignment.

[sunshowers]

That is nowhere close to the experience Gerrit and Phabricator have, where you can diff two arbitrary versions in history. Comments on previous versions also get lost along the way.

[sefrost]

Personally I find this feature works 50% of the time, and I don’t understand why.

[pavon]

IMO not using horrible opaque change IDs is one of the best parts of this. If I wanted it to work like Gerrit, I would just be using Gerrit.

[sunshowers]

You don't have to expose change IDs in the UI other than as a secondary thing! The current integer index would work just fine.

[gsnedders]

And enough of the time you can just match based on subject line, similar to how fixup/squash commits work with autosquash.

There’s enough ways you can match up commits, with plenty of prior art in this space.