4 ms·

I think the authors point is that some changes are so minor that elaboration is not required, like changing indentation. Elaborate commit messages are great, a

by cerved 3y ago

I think the authors point is that some changes are so minor that elaboration is not required, like changing indentation. Elaborate commit messages are great, and most people write commit messages that could be more elaborate. But most people also tend to squash several changes together, because it's easier. Being overzealous about writing elaborate commit messages for minor cookies is IMHO probably counter productive.

lexicality 3y ago
No change is minor enough that you don't need to explain what it does. If the commit message is "fix indentation" then I will ignore it and skip over it while searching the commit history. If it's "minor" or "fix" then I have to open the commit and look to see what it actually is. These "minor cookies" add up rapidly. (side note, people that squash important changes together are also on The List)
- cerved 3y ago
  Let's not forget people that commit trailing whitespace, or different line-endings. Can we put those on a separate List?
  - Vinnl 3y ago
    To be fair, we've got computers (CI, pre-commit hooks) that can stop that.
    - sgarland 3y ago
      To be pragmatic, the number of times I’ve had to fix or outright create CI for other teams because they didn’t bother to add these basics is too damn high. For anything with my team (or personal projects), where I can be guaranteed everyone understands exactly what I’ve set up, I add a pre-commit hook to fix minor linting issues and then add the change to the commit. If black, tf fmt, shfmt, etc. can just fix the problem, then do so, and don’t bother asking me if I’m sure.
- Aeolun 3y ago
  I love the ‘merge commit for my feature branch with 100 commits, but squash for merging release branch to master’ type. It’s as if a thousand commits cried out in anguish and were suddenly silenced.
Arch-TK 3y ago
> I think the authors point is that some changes are so minor that elaboration is not required, like changing indentation. Is the change _just_ changing indentation or is it changing something else which is hidden by a bunch of indentation changes? The difference between a commit message like "reindent" and "." is that the former makes it clear that the change is intended to be completely superficial and (unless you're writing python) should have no impact on anything. Now the person who wrote that commit message may be lying, or may have made a mistake, but, with even a commit message such as "reindent", it's much easier/faster to approach the issue if your bisect lands on such a commit message as you can go straight for "well let's normalize both versions to see if there's an accidental change hidden in here" rather than getting frustrated trying to figure out what the commit was about. > But most people also tend to squash several changes together, because it's easier. Don't. I also disagree with the author of the article about having an unclean history, it's not that hard to keep a clean history and, combined with actually properly splitting and isolating changes, makes it much easier to review the code. Proper use of git isn't solely centred around making bisect work.

by cerved 3y ago

lexicality 3y ago

No change is minor enough that you don't need to explain what it does. If the commit message is "fix indentation" then I will ignore it and skip over it while searching the commit history. If it's "minor" or "fix" then I have to open the commit and look to see what it actually is. These "minor cookies" add up rapidly. (side note, people that squash important changes together are also on The List)

cerved 3y ago
Let's not forget people that commit trailing whitespace, or different line-endings. Can we put those on a separate List?
- Vinnl 3y ago
  To be fair, we've got computers (CI, pre-commit hooks) that can stop that.
  - sgarland 3y ago
    To be pragmatic, the number of times I’ve had to fix or outright create CI for other teams because they didn’t bother to add these basics is too damn high. For anything with my team (or personal projects), where I can be guaranteed everyone understands exactly what I’ve set up, I add a pre-commit hook to fix minor linting issues and then add the change to the commit. If black, tf fmt, shfmt, etc. can just fix the problem, then do so, and don’t bother asking me if I’m sure.
Aeolun 3y ago
I love the ‘merge commit for my feature branch with 100 commits, but squash for merging release branch to master’ type. It’s as if a thousand commits cried out in anguish and were suddenly silenced.

Arch-TK 3y ago

> I think the authors point is that some changes are so minor that elaboration is not required, like changing indentation. Is the change _just_ changing indentation or is it changing something else which is hidden by a bunch of indentation changes? The difference between a commit message like "reindent" and "." is that the former makes it clear that the change is intended to be completely superficial and (unless you're writing python) should have no impact on anything. Now the person who wrote that commit message may be lying, or may have made a mistake, but, with even a commit message such as "reindent", it's much easier/faster to approach the issue if your bisect lands on such a commit message as you can go straight for "well let's normalize both versions to see if there's an accidental change hidden in here" rather than getting frustrated trying to figure out what the commit was about. > But most people also tend to squash several changes together, because it's easier. Don't. I also disagree with the author of the article about having an unclean history, it's not that hard to keep a clean history and, combined with actually properly splitting and isolating changes, makes it much easier to review the code. Proper use of git isn't solely centred around making bisect work.