7 ms·

>Most people however dont mind them at all and they practically do zero harm. They don't do zero harm though. The git blame history gets thrashed. If I see the

by bilalq 6y ago

>Most people however dont mind them at all and they practically do zero harm. They don't do zero harm though. The git blame history gets thrashed. If I see the last change one line 15 of a file is associated with a commit titled `Enable TCP connection reuse`, I'm going to wonder what a change to a line throwing an unrelated exception has to do with that. This means I'll waste time investigating a red herring. If I need to see the blame to find out who to ask about the feature, I also get garbage direction. The same preference for semantic commits applies to things like optimizations. Don't sneak in keep alive timeout changes in the same commit as `Add email notification support`. If a bug turns up on the email feature, I don't want to waste time potentially looking at the wrong thing. > However, forcing people to split it into two commits likely means it wont ever get done. That's not been my experience. They either get corrected at code review time on first release, or someone will make a semantically isolated commit for the fixes and include them in a future code review/pull request. > Because who wants to go through previous commit files to check for typos in other peoples code. People wont, either they fix it as they are noticing them or not at all. Not sure what point you're making here. You don't need to go through previous commits to see typos if they're still there in the current commit.

watwut 6y ago
You have to go through them to find the typos again. So you wont. The harm to history is marginal. It is quite unlikely that you fixed that many typos in all surrounding lines. I have yet to be confused by history like that.
- 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 ago
    So 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 ago
      Yes, 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 ago
        customer impact*
Cthulhu_ 6y ago
> They don't do zero harm though. The git blame history gets thrashed. That's exactly it; the keyword here is 'churn'. There was one OS project (I'm sure there's more) that basically said that small (typo, style) pull requests will not be accepted for that very reason. But that's where gratuitous code review, tooling, and rebasing come in; ideally a feature is complete and reviewed and tidy before it gets merged into master and 'solidified' as part of a project's history. Ideally anyway.

by bilalq 6y ago

watwut 6y ago

You have to go through them to find the typos again. So you wont. The harm to history is marginal. It is quite unlikely that you fixed that many typos in all surrounding lines. I have yet to be confused by history like that.

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 ago
  So 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 ago
    Yes, 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 ago
      customer impact*

Cthulhu_ 6y ago

> They don't do zero harm though. The git blame history gets thrashed. That's exactly it; the keyword here is 'churn'. There was one OS project (I'm sure there's more) that basically said that small (typo, style) pull requests will not be accepted for that very reason. But that's where gratuitous code review, tooling, and rebasing come in; ideally a feature is complete and reviewed and tidy before it gets merged into master and 'solidified' as part of a project's history. Ideally anyway.