[boolemancer]

That seems like significantly more work for marginal (if any) benefit over just having a single squash commit per PR.

I don't think I've ever found myself in a situation where I needed more granularity than the PR level when looking back through the history of a repo.

What are the situations where this is actually useful enough to make it worth the effort?

[mathstuf]

I've used it many times. Not just for my changes, but over others' changes. In CMake, we rewrite branches heavily to keep a sensible history within MRs. Not all changes make sense landing commit-by-commit yet also work as a single commit. It also allows for much easier reverting of specific changes in case some part of a topic needs removed.

Some examples:

- https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9486...

One commit to improve messages; another to add a test case that also uses these messages. Forcing separate CI runs for these dependent commits doesn't make sense, but they also don't belong in a single commit.

- https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8996...

Adds two test cases for a regression and then finally reverts the specific regression-exposing commit from https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8197... while keeping the still-good parts. If the 8197 merge had been squashed, one would have had to manually bisect the hunks to find out which one actually caused the problem.

[boolemancer]

> It also allows for much easier reverting of specific changes in case some part of a topic needs removed.

I guess I struggle to see where reverting entire commits makes more sense than just deleting the offending code in a new commit.

[mathstuf]

Even if that were the case, being able to bisect using `git bisect` over the logical hunks instead of having to manually bisect over them can help determine which code needs deleted without going overboard.