5 ms·

> I write my comments in commit messages because those are valid forever. Don’t they disappear when someone squash merges branch where a file is both renamed a

> I write my comments in commit messages because those are valid forever. Don’t they disappear when someone squash merges branch where a file is both renamed and changed (a lot)? Or, at least, when somebody decides to move to code to another repo, and doesn’t bother bringing the git history along.

cerved 5y ago
squash merge is evil
- usr1106 5y ago
  The author should squash useless commits. A readable series of commits is put to review. At merging to a commonly used branch no more squashing.
  - cerved 5y ago
    Why? Why doesn't the author make commits that are not useless? Why squash everything into a single commit? Why not 2 commits, 3, 5?
- reidjs 5y ago
  I feel differently, why don’t you like it?
  - notfed 5y ago
    The above-posted scenario is a great reason to hate it. It's destroying developers' documented rationale for each change.
  - cerved 5y ago
    it destroys information for no good reason
zerocount 5y ago
Yep. I make a commit on every little change and every team I've been on makes me squash them on merge. Comments in Git commits are bad. Just comment the code and make sure the comments are updated while you're in the code. You can also look at them in a code review. The argument that they get outdated is easily remedied, but people just want to keep claiming they write 'self documented code.'
- AlexCoventry 5y ago
  Everyone has to be onboard for that to work. Lots of people just never look at comments because they don't trust them.
- Zitrax 5y ago
  Git commit messages and code comments serve very different purposes, I don't see any reason to try to use one for the other or opposite. To me both are important but for different reasons. I don't want to search the blame history of a line of code if a simple comment had been enough, neither would I want to primarily use code comments when bisecting.
- johnisgood 5y ago
  I dunno if he really meant that, or just said he is explaining the added functionality in detail. I do explain in the commit message the feature I have just added.
- u801e 5y ago
  > make sure the comments are updated while you're in the code. You can also look at them in a code review. People will invariably forget to update comments and unless the comments show up in context lines of the diff associated with a change, it's likely that reviewers will overlook the need to change them.
  - Gibbon1 5y ago
    You comment is a standard explanation for not having comments. Always makes me wonder why stale comments aren't flagged during code review? Seriously failure to update comments should eventually lead to constructive dismissal.
jt2190 5y ago
> … when someone squash merges… It depends on who the “someone” is I suppose. I typically squash my own commits, and as part of that I aggregate all of the commit messages into a single message with all of the relevant details (and leave out the “fixed typo” type stuff that’s not relevant.) From the complaints that people are raising here there must be dev shops where someone else decides to squash a bunch of commits and throw away the messages.

cerved 5y ago

squash merge is evil

usr1106 5y ago
The author should squash useless commits. A readable series of commits is put to review. At merging to a commonly used branch no more squashing.
- cerved 5y ago
  Why? Why doesn't the author make commits that are not useless? Why squash everything into a single commit? Why not 2 commits, 3, 5?
reidjs 5y ago
I feel differently, why don’t you like it?
- notfed 5y ago
  The above-posted scenario is a great reason to hate it. It's destroying developers' documented rationale for each change.
- cerved 5y ago
  it destroys information for no good reason

zerocount 5y ago

Yep. I make a commit on every little change and every team I've been on makes me squash them on merge. Comments in Git commits are bad. Just comment the code and make sure the comments are updated while you're in the code. You can also look at them in a code review. The argument that they get outdated is easily remedied, but people just want to keep claiming they write 'self documented code.'

AlexCoventry 5y ago
Everyone has to be onboard for that to work. Lots of people just never look at comments because they don't trust them.
Zitrax 5y ago
Git commit messages and code comments serve very different purposes, I don't see any reason to try to use one for the other or opposite. To me both are important but for different reasons. I don't want to search the blame history of a line of code if a simple comment had been enough, neither would I want to primarily use code comments when bisecting.
johnisgood 5y ago
I dunno if he really meant that, or just said he is explaining the added functionality in detail. I do explain in the commit message the feature I have just added.
u801e 5y ago
> make sure the comments are updated while you're in the code. You can also look at them in a code review. People will invariably forget to update comments and unless the comments show up in context lines of the diff associated with a change, it's likely that reviewers will overlook the need to change them.
- Gibbon1 5y ago
  You comment is a standard explanation for not having comments. Always makes me wonder why stale comments aren't flagged during code review? Seriously failure to update comments should eventually lead to constructive dismissal.

jt2190 5y ago

> … when someone squash merges… It depends on who the “someone” is I suppose. I typically squash my own commits, and as part of that I aggregate all of the commit messages into a single message with all of the relevant details (and leave out the “fixed typo” type stuff that’s not relevant.) From the complaints that people are raising here there must be dev shops where someone else decides to squash a bunch of commits and throw away the messages.