Hacker News Reader

Comment by mojuba | Hacker News Reader

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.

View on HN

I 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.

Except 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.

Also: avoid using comments where proper names would suffice:

  // cleans responses
  function zrgfy(response){
    ...
  }

should be something like:

  function cleanResponse(response){
    ...
  }

My 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.

A 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.

The 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.

Highly disagree. As long as the code lives, the commit lives.

until 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

What is "The Git Killer"?

That'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), although Pijul specifically won't become popular because it's licensed under AGPL3.

yep 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.

I 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.

We 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.

Reply on news.ycombinator.com