4 ms·

I agree with you about the importance of commit messages, but the problem with using them in place of comments is that commit messages become much harder to fin

I agree with you about the importance of commit messages, but the problem with using them in place of comments is that commit messages become much harder to find as the history becomes longer, as opposed to comments which will always be immediately visible for as long as they are relevant.

jacques_chester 7y ago
This is what git blame is for. Comments are notorious for drifting out of sync with reality.
- umvi 7y ago
  Git blame only shows you the last person that touched the line, not the person who introduced a breaking change to that line (but it wasn't caught for weeks/months). Comments are just as cheap as commit messages. Why not both?
  - jacques_chester 7y ago
    It shows you the commit that introduced the current version of the line. That's what you want if you want to understand the current version of the line. I feel like I'm missing something here. I hate this feeling of impending dumb.
    - williamdclt 7y ago
      A line can have been touched multiple times since the breaking change (simplest example: indentation/formatting)
      - jacques_chester 7y ago
        Got it. It's still possible to keep stepping back through the history of that line to understand its exact history. I also typically find most files have only a handful of commits of interest in their history, so scoping a git log to the file often gets me within spitting distance of the right commit, if someone took the time to write a good one. Edit: which goes back to my original point, that the commit is the best time and place to snapshot the meaning of that time and that place.
        umvi 7y ago
        I agree, but you must also concede that not all developers are as proficient at git as you and might not be aware of such debugging/detective techniques. These same developers tend to favor print statements for debugging instead of an actual debugger. Also, not every developer has the privilege of using a DCVS like git. For them, a comment in the code could save a lot of time and hassle.
        jacques_chester 7y ago
        Fair points. Though I hope people at gitlab use git.
  - RodgerTheGreat 7y ago
    Git blame can also show you the last revision which touched a file since some revision. Git log on a file can show you all the revisions in which it was touched. Using these together lets you slice the history in many useful ways, and there are countless gui-based tools (git gui, for example) which also allow you to explore revisions.
    - RussianCow 7y ago
      None of that is as effortless as looking up at the comment on the previous line.
      - jacques_chester 7y ago
        But which is more effortful to keep accurate. Whereas the commit is immutably and ideally exactly about what it's about. There is no better time to capture the information in a way that perfectly connects it to what it's describing.
        elygre 7y ago
        While commit messages are always there, they get lost. You fix a bug in your code, with a commit message. Later, you realize that this function is super reusable, so you move the function to another class in another file. Now, for all intents and purposes, the original commit message will never be seen again.
        jacques_chester 7y ago
        It's harder to find originals under such circumstances, sure. But I don't see this as a reason for never writing good messages, because a journal of intent is strictly better than a journal of physical amendments. That something needs to be entirely perfect before being judged better than the status quo is the Nirvana fallacy.
        RussianCow 7y ago
  - hinkley 7y ago
    It's more accurate to say that git blame has that information but doesn't make it especially easy to get to.

jacques_chester 7y ago

This is what git blame is for. Comments are notorious for drifting out of sync with reality.

umvi 7y ago
Git blame only shows you the last person that touched the line, not the person who introduced a breaking change to that line (but it wasn't caught for weeks/months). Comments are just as cheap as commit messages. Why not both?
- jacques_chester 7y ago
  It shows you the commit that introduced the current version of the line. That's what you want if you want to understand the current version of the line. I feel like I'm missing something here. I hate this feeling of impending dumb.
  - williamdclt 7y ago
    A line can have been touched multiple times since the breaking change (simplest example: indentation/formatting)
    - jacques_chester 7y ago
      Got it. It's still possible to keep stepping back through the history of that line to understand its exact history. I also typically find most files have only a handful of commits of interest in their history, so scoping a git log to the file often gets me within spitting distance of the right commit, if someone took the time to write a good one. Edit: which goes back to my original point, that the commit is the best time and place to snapshot the meaning of that time and that place.
      - umvi 7y ago
        I agree, but you must also concede that not all developers are as proficient at git as you and might not be aware of such debugging/detective techniques. These same developers tend to favor print statements for debugging instead of an actual debugger. Also, not every developer has the privilege of using a DCVS like git. For them, a comment in the code could save a lot of time and hassle.
        jacques_chester 7y ago
        Fair points. Though I hope people at gitlab use git.
- RodgerTheGreat 7y ago
  Git blame can also show you the last revision which touched a file since some revision. Git log on a file can show you all the revisions in which it was touched. Using these together lets you slice the history in many useful ways, and there are countless gui-based tools (git gui, for example) which also allow you to explore revisions.
  - RussianCow 7y ago
    None of that is as effortless as looking up at the comment on the previous line.
    - jacques_chester 7y ago
      But which is more effortful to keep accurate. Whereas the commit is immutably and ideally exactly about what it's about. There is no better time to capture the information in a way that perfectly connects it to what it's describing.
      - elygre 7y ago
        While commit messages are always there, they get lost. You fix a bug in your code, with a commit message. Later, you realize that this function is super reusable, so you move the function to another class in another file. Now, for all intents and purposes, the original commit message will never be seen again.
        jacques_chester 7y ago
        It's harder to find originals under such circumstances, sure. But I don't see this as a reason for never writing good messages, because a journal of intent is strictly better than a journal of physical amendments. That something needs to be entirely perfect before being judged better than the status quo is the Nirvana fallacy.
        RussianCow 7y ago
- hinkley 7y ago
  It's more accurate to say that git blame has that information but doesn't make it especially easy to get to.