[teeray]

It’s the “well-curated” part. Many folks treat commits like video game save points, and find providing any kind of message burdensome (e.g. “fix bug”, “do work”). This alone is fine, but then they can’t be bothered to go back and clean it up with `git rebase -i`, so you end up with a mountain of trash in your git log if you don’t turn on mandatory squash and merge. For these folks, the PR becomes the commit. Stacked PRs is revolutionary because it’s as though these developers can finally have multiple commits which comprise a change.

[ghthor]

This is it, but also, because there was no way of asking a reviewer to review a single commit and then merge only that commit out of 2+ commits without a lot of ceremony, work streams had to be completely orthogonal to parallelize anything . Now I can fully develop a sequence of 20 changes (each a single commit) and start getting reviews and merging while still progressing towards the goal. I’ve been doing this for 2years with graphite and more before that manually or in other systems/cultures that actually can review a commit/patch and merge that thing.

Honestly all GitHub needed to do was make reviewing and merging commit(s) from a PR possible and that would also been neat.

[chillfox]

There is real value in having all the messy commit history, especially now with AI, but you do need some kind of description on them that indicates what they are.

One use I have got from it is asking an agent to go through the git history and categories the mistakes/bugs, then turn the common ones into CI checks or AGENTS.md rules.

A well curated history just hides a lot of valuable info.

[eddythompson80]

> (e.g. “fix bug”, “do work”)

or "skjdnfks" and "fsdfs" commits.