7 ms·

That’s horrible because the git commit messages are easily lost, disconnected or hard to find in any reasonably active codebase. For example as soon as you do a

That’s horrible because the git commit messages are easily lost, disconnected or hard to find in any reasonably active codebase. For example as soon as you do a change and move a file it almost always disconnects from the previous change history. Whats even more difficult is searching through a code base when the documentation isn’t in or near the code. I don’t know any IDE or editor that makes it easy to search though git commit message and source code at the same time. On top of that, do you review git commit message in code review? Do you aks people to improve descriptions, typos and language in commit messages?

cerved 5y ago
git log --follow -p file edit: here's another git log -p -L:show_commit:builtin/rev-list.c
b3morales 5y ago
> On top of that, do you review git commit message in code review? Do you aks people to improve descriptions, typos and language in commit messages? Absolutely I do. The commit message is part of the commit just like the code; why would it be excluded from review? The number of times that a good commit message has helped me when dealing with a bug, and that a poor one has stymied me, have firmly convinced me that they are just as important as any other project documentation. They should be clear and informative, and I ask for those aspects to be improved when needed.
sildur 5y ago
> I don’t know any IDE or editor that makes it easy to search though git commit message and source code at the same time. Any editor from Jetbrains with the GitToolbox plugin does that.
- 9dev 5y ago
  Can second that. Having the commit message as a virtual comment on the end of the current line is immensely helpful in tracking changes. It’s like git blame on steroids.
  - prometheon1 5y ago
    I also like seeing the commit messages in this way! In the case of VSCode this comes with the Git Lens extension.
locallost 5y ago
I don't understand how they are hard to find. It's trivial to find where the file was moved from. What I truly care about is why something is the way it is, what is the rationale behind it, how it works with other parts of the codebase, what problems it solves, what is tricky about it, what to pay attention to and so on. I don't care at all about the code that was written and an explanation to it because this I can read myself in the code. The best place I've found for this is a code commit because it can tie different parts of the codebase together and add a lot of context to a change. I commit heavily and don't squash. A long comment in a commit that contains all file changes related to a certain feature, bug or whatever adds a lot more information than a comment in one file. When other people do it, it helps me a lot more than chasing their (outdated) code comments throughout the codebase. But if that doesn't work for you, then don't do it. Just don't be dogmatic and dismissive. I accept there might be situations and codebases where this doesn't work.
- cerved 5y ago
  Lot's of IDEs and external tools do very basic git integration ¯\_(ツ)_/¯ I think JetBrains is probably the best of the IDEs
- fenomas 5y ago
  I'm lost. Are you talking about meta-level comments, like "here's why this change is being made", that aren't directly tied to any particular line of code? If so, certainly putting that stuff in commits makes sense. But for regular "explanatory note about this variable/function/etc" comments, how does one work if those things are in commit logs? If you're reading code and something is unclear, do you look back through the commit messages of every commit that's ever touched that line, just in case one of them has something relevant?
  - treis 5y ago
    IDEs can show commit history. But you're right that it can get messy tracing back to the original commit when a file has been changed many times. But for the most part I feel like comments should be automated tests. If a line is there for an edge case it should have a matching test for that edge case. The only exceptions I see are for performance optimizations or some other situation where you can't easily test.
masklinn 5y ago
Your comments applies very little to commit messages, and much more so to comments. > That’s horrible because the git commit messages are easily lost, disconnected or hard to find in any reasonably active codebase. For example as soon as you do a change and move a file it almost always disconnects from the previous change history. Learn your tools or get better ones, `git log --follow` has no issues with renames, and when files get munged in ways it can't handle (e.g. content is split out or merged) it's easy enough to stitch back, and good annotate UIs (Jetbrain's is stellar and one of the few things I don't use magit for) make flitting through a snippet's history trivial. Meanwhile finding removed comments is nearly impossible (VCS are nowhere near as good for finding when was removed than when it was added), and comments can easily drift apart from their point of origin as developers aren't too careful about maintaining them when adding unrelated comments. > On top of that, do you review git commit message in code review? Do you aks people to improve descriptions, typos and language in commit messages? Bet your ass I do.

cerved 5y ago

git log --follow -p file edit: here's another git log -p -L:show_commit:builtin/rev-list.c

b3morales 5y ago

> On top of that, do you review git commit message in code review? Do you aks people to improve descriptions, typos and language in commit messages? Absolutely I do. The commit message is part of the commit just like the code; why would it be excluded from review? The number of times that a good commit message has helped me when dealing with a bug, and that a poor one has stymied me, have firmly convinced me that they are just as important as any other project documentation. They should be clear and informative, and I ask for those aspects to be improved when needed.

sildur 5y ago

> I don’t know any IDE or editor that makes it easy to search though git commit message and source code at the same time. Any editor from Jetbrains with the GitToolbox plugin does that.

9dev 5y ago
Can second that. Having the commit message as a virtual comment on the end of the current line is immensely helpful in tracking changes. It’s like git blame on steroids.
- prometheon1 5y ago
  I also like seeing the commit messages in this way! In the case of VSCode this comes with the Git Lens extension.

locallost 5y ago

I don't understand how they are hard to find. It's trivial to find where the file was moved from. What I truly care about is why something is the way it is, what is the rationale behind it, how it works with other parts of the codebase, what problems it solves, what is tricky about it, what to pay attention to and so on. I don't care at all about the code that was written and an explanation to it because this I can read myself in the code. The best place I've found for this is a code commit because it can tie different parts of the codebase together and add a lot of context to a change. I commit heavily and don't squash. A long comment in a commit that contains all file changes related to a certain feature, bug or whatever adds a lot more information than a comment in one file. When other people do it, it helps me a lot more than chasing their (outdated) code comments throughout the codebase. But if that doesn't work for you, then don't do it. Just don't be dogmatic and dismissive. I accept there might be situations and codebases where this doesn't work.

cerved 5y ago
Lot's of IDEs and external tools do very basic git integration ¯\_(ツ)_/¯ I think JetBrains is probably the best of the IDEs
fenomas 5y ago
I'm lost. Are you talking about meta-level comments, like "here's why this change is being made", that aren't directly tied to any particular line of code? If so, certainly putting that stuff in commits makes sense. But for regular "explanatory note about this variable/function/etc" comments, how does one work if those things are in commit logs? If you're reading code and something is unclear, do you look back through the commit messages of every commit that's ever touched that line, just in case one of them has something relevant?
- treis 5y ago
  IDEs can show commit history. But you're right that it can get messy tracing back to the original commit when a file has been changed many times. But for the most part I feel like comments should be automated tests. If a line is there for an edge case it should have a matching test for that edge case. The only exceptions I see are for performance optimizations or some other situation where you can't easily test.

masklinn 5y ago

Your comments applies very little to commit messages, and much more so to comments. > That’s horrible because the git commit messages are easily lost, disconnected or hard to find in any reasonably active codebase. For example as soon as you do a change and move a file it almost always disconnects from the previous change history. Learn your tools or get better ones, `git log --follow` has no issues with renames, and when files get munged in ways it can't handle (e.g. content is split out or merged) it's easy enough to stitch back, and good annotate UIs (Jetbrain's is stellar and one of the few things I don't use magit for) make flitting through a snippet's history trivial. Meanwhile finding removed comments is nearly impossible (VCS are nowhere near as good for finding when was removed than when it was added), and comments can easily drift apart from their point of origin as developers aren't too careful about maintaining them when adding unrelated comments. > On top of that, do you review git commit message in code review? Do you aks people to improve descriptions, typos and language in commit messages? Bet your ass I do.