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

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/commits 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/commits 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/commits 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.