I on the other hand have never come across a scenario where I run git bisect to find a commit that broke something, discover a small commit as a culprit and wish I had instead found a commit that's hundreds of lines long.
What has happened a whole lot though is the exact opposite.
It might be better to view a commit as a natural unit of working code. There are a lot of units of working code which would be tedious to be introduced as a only a few lines.
As such, a new codebase is likely to grow by large unwieldy commits and a mature one by targetted small commits.
For me, all the code in the PR at that point is in question. The code was changed as part of a bigger part of work and reverting it without understanding why might cause issues back the other way.
The other thing to say - that is missing from this conversation - is that if you’re using github, the original commits are still against the PR.
Our strategy is to squash on merge and ensure the JIRA ticket reference is in the MR title. You have the granularity of the feature which is going to help guide you on the intention. It's also much easier to enforce. People like to write and commit code in their own way.
Normal_gaussian|9 days ago
As such, a new codebase is likely to grow by large unwieldy commits and a mature one by targetted small commits.
aidos|8 days ago
The other thing to say - that is missing from this conversation - is that if you’re using github, the original commits are still against the PR.
StrangeSound|8 days ago