3 ms·
You can fix them as you find them. Just save as a separate commit. No need to go back to find anything. Typos were just an example. There are other changes tha
by bilalq 6y ago
You can fix them as you find them. Just save as a separate commit. No need to go back to find anything.
Typos were just an example. There are other changes that are just as harmful to history that people might otherwise think are safe to squeeze in. Examples include whitespace changes and minor refactors. All of these can really mess with history and make things confusing. Refactors in particular really mess with your head and can even make the code review step confusing if the review wasn't sent with multiple commits.
Keeping semantic isolation of commits has value in its neatness. You may be able to get by without doing so, but you'll be better off if you did.
- watwut 6y agoSo I will commit half file in one comit and second in another? Really not worth the risk not time. History is not that epically useful that we should avoid cleanups.
- bilalq 6y agoYes, you can commit parts of a file at a time. This is easily done by using `git add -p`. This is a subjective matter, so I don't think your point of view here is wrong or anything, but I do disagree with it. History is something I've consulted many, many times on large code bases. It's helped save precious minutes while triaging situations where an alarm went off and customer was ongoing.
- bilalq 6y agocustomer impact*