19 ms·

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

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 2y ago
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.
- boolemancer 2y ago
  > 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 2y ago
    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.

mathstuf 2y ago

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.

boolemancer 2y ago
> 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 2y ago
  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.