4 ms·
Should be noted, it is often tempting to describe everything about the change in the commit description rather than comments in the code. Remember, git commits
by mojuba 10y ago
Should be noted, it is often tempting to describe everything about the change in the commit description rather than comments in the code. Remember, git commits disappear from sight pretty soon and become fossils, whereas there may be something important that should be said in the code itself.
- karim 10y agoI think that on the contrary, everything should be in the commit. The commit message is dated, it has an author and a context. How often do you come across stray comments which shouldn't be here because the code got refactored away? Commis are often just a git blame away anyway.
- Cthulhu_ 10y agoExcept when a line has been changed over a longer period of time. Although maybe I'm just not comfortable with tracking history too much, because in the applications I generally work on (customer-facing webapps) we generally don't need to look back in history too much.
- nailer 10y agoAlso: avoid using comments where proper names would suffice: // cleans responses function zrgfy(response){ ... } should be something like: function cleanResponse(response){ ... }
- chousuke 10y agoMy rule of thumb in commenting is that I comment the why or how, not the what... Unless the what is sufficiently non-obvious, in which case it is usually prudent to have a really good explanation of the why, as well.
- deleted 10y ago[deleted]
- nevon 10y agoHighly disagree. As long as the code lives, the commit lives.
- jbattle 10y agountil the git killer comes along and the team decides how much history they are willing to migrate. I've seen it happen every 5(?) years across several companies. Ironically it's always the oldest commit messages that turn out to be the most valuable because newer changes people remember
- k__ 10y agoWhat is "The Git Killer"?
- telotortium 10y agoThat's just a generic stand-in for any new version control system that becomes popular enough to display Git. For example, Pijul (https://pijul.org https://pijul.org), although Pijul specifically won't become popular because it's licensed under AGPL3.
- jbattle 10y agoyep as telo.. said - whatever will inevitably supercede git. In my own work it was VSS > Perforce > svn > git All of those were good choices when they were new, and suboptimal choices when the next better solution came along.
- k__ 10y agoI had the feeling companies would just stick to their thing. Last I worked with used CVS and always talked about switching to SVN, but never did.
- Macha 10y agoWe have CVS, SVN, a legacy internal tool for managing git repos and most recently, Bitbucket. And some of these repos go back years. So companies do migrate version control systems.
- lysis 10y agoA commit doesn't suffer from the same bit rot as a comment. Descriptions of how code changes doesn't shift as much as description of how code operates. If git blame, git log, and git diff are part of your workflow finding a git commit describing a piece of code is easy.
- makecheck 10y agoThe commit message is frequently the only comment that ties the set of changes together so it is a good place to describe the change as a whole. This is not always clear when looking at any particular function, for example.