No, we're not talking about the final timeline. That is finalised when (or if) code is merged to the mainline. We're talking about what happens when the command "git commit" is executed.
Ok, if you're talking about just WIP commits that will be squashed and will never be part of mainline, then shrug.
For me that's a tiny proportion of commits. I'd rather avoid taking a whole finished feature branch and then spend more time cleaning up a sloppy commit history.
And commit in such that the final timeline has broken tests for half of commits?
Sounds like an awful way to live your life.
No, we're not talking about the final timeline. That is finalised when (or if) code is merged to the mainline. We're talking about what happens when the command "git commit" is executed.
Ok, if you're talking about just WIP commits that will be squashed and will never be part of mainline, then shrug.
For me that's a tiny proportion of commits. I'd rather avoid taking a whole finished feature branch and then spend more time cleaning up a sloppy commit history.
Sure, sometimes it's correct to squash, but for nontrivial changes I go with https://github.com/google/eng-practices/blob/master/review/d...