4 ms·
It's a bit heavy handed, but I believe the rules are more like best practices. If you're fixing typos in new code I see no reason to have the history of introd
by evandale 4y ago
It's a bit heavy handed, but I believe the rules are more like best practices.
If you're fixing typos in new code I see no reason to have the history of introducing the typo and then fixing it. If you've come across a typo in a file you're editing then by all means make that typo fix in its own commit.
It gets worse when you start fixing typos in files unrelated to your fix. One of those small typo fixes could introduce a bug and multiple commits makes it easier to track down. Blame would pinpoint it exactly - you'll see Bob's "Fix a typo" commit instead of being buried in Bob's "Add trucks to the game" commit. That saves you from having to go look at the PR or diff and to figure out why Bob renamed cares to cars.
- lamontcg 4y ago> It gets worse when you start fixing typos in files unrelated to your fix. That does not go into the PR and someone should make you split that out into a code-cleanup PR and it shouldn't pass review.