I think a useful question here is “what is a good commit?”, specifically at the MR stage. I don’t care what commits look like on your local machine.
I tend to like to treat commits at that stage as complete, atomic thoughts.
“This commit is a refactor of this function name”
“This commit defines all the data classes we’ll use”
“This commit writes the new function and all its tests”
“This commit injects the new code into the old path with a feature flag”
“This commit fixes the tests that broke from that change”
Some of these would be better served as separate MRs entirely; but I imagine my idea stands.
I primarily care about the pull request title and description since we squash-merge and those values end up populating the squashed commit.