4 ms·

> The purpose of a git commit message is to answer the question “why does this commit exist?” Why? Every time I have asked this people say because you'll searc

> The purpose of a git commit message is to answer the question “why does this commit exist?” Why? Every time I have asked this people say because you'll search the logs (which I have never done in my life) or because "it's good practice"

fraudsyndrome 4y ago
Doesn't mean others are in the same boat as you. The team I work on frequently write detailed commits to the point where I can (and have several times) successfully searched information from years ago on a block of code with the ticket number and the developers (even myself) reasoning at the time. Maybe it depends on the project but I've found myself doing this so often that I won't stop, it's such a small task that has given me so much benefit. If it doesn't help anyone then nothing was lost.
- ArrayBoundCheck 4y ago
  Why are you searching a year or more back? Is this using git blame?
  - shakna 4y ago
    To explain why a certain block of code exists. When the code came into existence is rarely that important. You just want to know why. Why does the code fence against a particular circumstance you didn't think should be possible? Why does it call out to something you think is unrelated? Those questions can be answered by a proper commit message.
    - ArrayBoundCheck 4y ago
      I set a breakpoint and run the test suite for that answer
      - fragmede 4y ago
        That answers what the code does, but not why it does what it does.
      - tuwtuwtuwtuw 4y ago
        So you never need to understand when or why a bug was introduced? Or you never need to understand why the current behavior as is it is?
        ArrayBoundCheck 4y ago
      - ArrayBoundCheck 4y ago
        dang 4y ago
        Could you please stop breaking the site guidelines? You've been doing it a lot lately, unfortunately. Not just with these off-topic complaints about downvoting, but with comments like these: https://news.ycombinator.com/item?id=32104697 https://news.ycombinator.com/item?id=32104697 https://news.ycombinator.com/item?id=32086054 https://news.ycombinator.com/item?id=32086054 https://news.ycombinator.com/item?id=32085905 https://news.ycombinator.com/item?id=32085905 https://news.ycombinator.com/item?id=32085736 https://news.ycombinator.com/item?id=32085736 We eventually ban accounts that carry on like this on HN. I don't want to ban you, so if you'd please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.
        ArrayBoundCheck 4y ago
        Some of those comments were in response to people calling me a liar with upvotes on their comments and downvotes on mine. It's incredibly irritating and frustrating when it appears those accusing me of lying not suffer any consequences. For example (one that you linked to) a person said I was wrong and his comment wasn't flagged yet when I asked him to stop replying to my comments (many of my comments in the thread weren't on his comments) mine gets flagged https://news.ycombinator.com/item?id=32086054 https://news.ycombinator.com/item?id=32086054
    - d3nj4l 4y ago
      Why don’t you put that as a comment on the code?
      - lexicality 4y ago
        Comments are for why code is written the way it is, commits are for why the code is written in the first place. You _could_ tag every line of code with // JIRA-123 The PM wants this to be blue but if you did it would become unreadable and wouldn't be kept up to date.
      - kazinator 4y ago
        Because if 37 changes are done to the same 15 line function over time, the amount of comment material will dwarf the function. And most of it will pertain to historic versions of the function which are not what actually appears below the comment; a comment made 13 revisions ago makes sense for the 13-revision-old version of the function.
        d3nj4l 4y ago
        You just update the comment?
    - kazinator 4y ago
      Sometimes, in some kinds of projects, the commit messages looks like this: JIRA: #1234 Adjusted the FOOBAR parameter from 42 to 73. To know the "why", you have to read the ticket; you will not find anything in the git log.
      - erik_seaberg 4y ago
        Oh jeez, please do not make me run “git log” and then open a hundred tabs in an old bug tracker that may or may not still exist to figure out when a problem may have been introduced. I want code reviewers to insist on at least somewhat useful messages for us to skim at 3 AM.
plorkyeran 4y ago
Never looking at git history is like, not reading comments or something. It's an incredibly valuable resource for understanding why the existing code is the way it is.
- ArrayBoundCheck 4y ago
  You didn't answer why. My code passes all the unit test and we almost always have real code using it immediately. The function works. Why am I reading it? The only thing I read are bug reports (usually a spec problem, not normally a logic bug) and new features, or test outputs
  - erik_seaberg 4y ago
    If someone complains that our system did something weird, sometimes it’s a mistake we can just fix, but sometimes it’s a non-obvious consequence of some requirement (which I might not have been aware of) that we have to explain to our consumer. It also helps a lot to tell whether it has been like that for a week or five years. I can’t even imaging having a spec that fully answers anything like this; Microsoft tried for that level of detail but I found they couldn’t keep it up to date.
    - ArrayBoundCheck 4y ago
  - NicoJuicy 4y ago
    Because you'd want to know why code does what it does. If a bug pops up, you'd want to know why some code exists and if the original premise of the code is as it should be or needs revision. I think it's very rare that a developer receives all that information up front in a team. Eg. Old codebase, lost knowledge or people leaving.
Larrikin 4y ago
I think you just haven't discovered you can? I don't know of anyone arbitrarily looking through logs, but it's incredibly useful with git blame when you get to a section of code and don't understand it or typically it's done in an odd or unintuitive way. The blame shows who wrote it, information as to what they were working on via the actual commit message, and branch information. If the person still works with you, you can just ask them about it. If they don't or you don't want to bother them, the commit message tells you what the change was and often times why to give you a better context. All the teams I've worked on included information like feature, bug, defect, and the associated ticket number in the branch name, so you have the information at hand to go look at the ticket directly and see what requirements were needed.
- ArrayBoundCheck 4y ago
  I'm starting to understand why. It appears my workflow has the information other people would want from a git log elsewhere (test, specs, examples, etc)
  - tuwtuwtuwtuw 4y ago
    Let's say you have some code written 2 years ago. 2 months ago someone made a bug fix in the code replacing a few of the lines. How would you know from test, specs or examples which specific lines were modified and by whom? I don't get it.
    - ArrayBoundCheck 4y ago
      Why would I want to do that? Usually if there's a problem I'll either write a new test or see if someone modified a test I thought was covering the case Usually people 'own' a file or part of the system so that wouldn't really be happening anyway
      - erik_seaberg 4y ago
        As I look at the top ten committers to our key service, two of us are still here, the other eight (including the lead from day one) switched teams or left the company over the last five years. Unfortunately I don’t think 27% turnover per year is unusually high in tech, so ownership isn’t a good replacement for written records.
Macha 4y ago
I work on several legacy codebases which were: - written by people who were not me - written by people who have since left the company - the original documentation has rotted away through wiki replacements, issue tracker replacements, or being lost via people turnover or system replacement. The result in many cases is the code is the _only_ documentation of the system behaviour, so seeing what was introduced together is important context to understanding why it is the way it is. I probably run git blame more than git commit at this point and there's a real QoL difference between the good commit messages and the "changes for ticket12345" commit messages.
tsimionescu 4y ago
If you have never needed to find out why a particular piece of code is the way it is, then you have been very lucky to work in very clean code bases. In my own experience, this has been an infrequent but inevitable part of work - maybe once a month or so, I have had to understand whether a particular piece of code, that seems wrong, had a good reason for existing or not. Sometimes it turned out to be a mistake in the original commit, or working around a limitation that no longer exists, other times it has saved me from re-introducing a bug that someone had spent effort fixing.
- kazinator 4y ago
  ArrayBoundCheck didn't say they never had to find out why a particular piece of code is the way it is, just that they didn't have to search through log messages. For isntance, when you use "git blame" and similar tools, the log messages are not involved. You might end up reading the log message of the commit that was responsible for a change, but you didn't search log messages to get there. In a project with poor commit messages, they will be of little use; reading them won't produce much value, let a lone searching. Anyway, that seems like the best possible interpretation of the user's comment, anyway.
  - yencabulator 4y ago
    tsimionescu didn't say anything about searching the logs. The commit message explains (/should explain) why the commit was made. That is useful even if you arrive at the commit via git blame, bisect, etc.

fraudsyndrome 4y ago

Doesn't mean others are in the same boat as you. The team I work on frequently write detailed commits to the point where I can (and have several times) successfully searched information from years ago on a block of code with the ticket number and the developers (even myself) reasoning at the time. Maybe it depends on the project but I've found myself doing this so often that I won't stop, it's such a small task that has given me so much benefit. If it doesn't help anyone then nothing was lost.

ArrayBoundCheck 4y ago
Why are you searching a year or more back? Is this using git blame?
- shakna 4y ago
  To explain why a certain block of code exists. When the code came into existence is rarely that important. You just want to know why. Why does the code fence against a particular circumstance you didn't think should be possible? Why does it call out to something you think is unrelated? Those questions can be answered by a proper commit message.
  - ArrayBoundCheck 4y ago
    I set a breakpoint and run the test suite for that answer
    - fragmede 4y ago
      That answers what the code does, but not why it does what it does.
    - tuwtuwtuwtuw 4y ago
      So you never need to understand when or why a bug was introduced? Or you never need to understand why the current behavior as is it is?
      - ArrayBoundCheck 4y ago
    - ArrayBoundCheck 4y ago
      - dang 4y ago
        Could you please stop breaking the site guidelines? You've been doing it a lot lately, unfortunately. Not just with these off-topic complaints about downvoting, but with comments like these: https://news.ycombinator.com/item?id=32104697 https://news.ycombinator.com/item?id=32104697 https://news.ycombinator.com/item?id=32086054 https://news.ycombinator.com/item?id=32086054 https://news.ycombinator.com/item?id=32085905 https://news.ycombinator.com/item?id=32085905 https://news.ycombinator.com/item?id=32085736 https://news.ycombinator.com/item?id=32085736 We eventually ban accounts that carry on like this on HN. I don't want to ban you, so if you'd please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.
        ArrayBoundCheck 4y ago
        Some of those comments were in response to people calling me a liar with upvotes on their comments and downvotes on mine. It's incredibly irritating and frustrating when it appears those accusing me of lying not suffer any consequences. For example (one that you linked to) a person said I was wrong and his comment wasn't flagged yet when I asked him to stop replying to my comments (many of my comments in the thread weren't on his comments) mine gets flagged https://news.ycombinator.com/item?id=32086054 https://news.ycombinator.com/item?id=32086054
  - d3nj4l 4y ago
    Why don’t you put that as a comment on the code?
    - lexicality 4y ago
      Comments are for why code is written the way it is, commits are for why the code is written in the first place. You _could_ tag every line of code with // JIRA-123 The PM wants this to be blue but if you did it would become unreadable and wouldn't be kept up to date.
    - kazinator 4y ago
      Because if 37 changes are done to the same 15 line function over time, the amount of comment material will dwarf the function. And most of it will pertain to historic versions of the function which are not what actually appears below the comment; a comment made 13 revisions ago makes sense for the 13-revision-old version of the function.
      - d3nj4l 4y ago
        You just update the comment?
  - kazinator 4y ago
    Sometimes, in some kinds of projects, the commit messages looks like this: JIRA: #1234 Adjusted the FOOBAR parameter from 42 to 73. To know the "why", you have to read the ticket; you will not find anything in the git log.
    - erik_seaberg 4y ago
      Oh jeez, please do not make me run “git log” and then open a hundred tabs in an old bug tracker that may or may not still exist to figure out when a problem may have been introduced. I want code reviewers to insist on at least somewhat useful messages for us to skim at 3 AM.

plorkyeran 4y ago

Never looking at git history is like, not reading comments or something. It's an incredibly valuable resource for understanding why the existing code is the way it is.

ArrayBoundCheck 4y ago
You didn't answer why. My code passes all the unit test and we almost always have real code using it immediately. The function works. Why am I reading it? The only thing I read are bug reports (usually a spec problem, not normally a logic bug) and new features, or test outputs
- erik_seaberg 4y ago
  If someone complains that our system did something weird, sometimes it’s a mistake we can just fix, but sometimes it’s a non-obvious consequence of some requirement (which I might not have been aware of) that we have to explain to our consumer. It also helps a lot to tell whether it has been like that for a week or five years. I can’t even imaging having a spec that fully answers anything like this; Microsoft tried for that level of detail but I found they couldn’t keep it up to date.
  - ArrayBoundCheck 4y ago
- NicoJuicy 4y ago
  Because you'd want to know why code does what it does. If a bug pops up, you'd want to know why some code exists and if the original premise of the code is as it should be or needs revision. I think it's very rare that a developer receives all that information up front in a team. Eg. Old codebase, lost knowledge or people leaving.

Larrikin 4y ago

I think you just haven't discovered you can? I don't know of anyone arbitrarily looking through logs, but it's incredibly useful with git blame when you get to a section of code and don't understand it or typically it's done in an odd or unintuitive way. The blame shows who wrote it, information as to what they were working on via the actual commit message, and branch information. If the person still works with you, you can just ask them about it. If they don't or you don't want to bother them, the commit message tells you what the change was and often times why to give you a better context. All the teams I've worked on included information like feature, bug, defect, and the associated ticket number in the branch name, so you have the information at hand to go look at the ticket directly and see what requirements were needed.

ArrayBoundCheck 4y ago
I'm starting to understand why. It appears my workflow has the information other people would want from a git log elsewhere (test, specs, examples, etc)
- tuwtuwtuwtuw 4y ago
  Let's say you have some code written 2 years ago. 2 months ago someone made a bug fix in the code replacing a few of the lines. How would you know from test, specs or examples which specific lines were modified and by whom? I don't get it.
  - ArrayBoundCheck 4y ago
    Why would I want to do that? Usually if there's a problem I'll either write a new test or see if someone modified a test I thought was covering the case Usually people 'own' a file or part of the system so that wouldn't really be happening anyway
    - erik_seaberg 4y ago
      As I look at the top ten committers to our key service, two of us are still here, the other eight (including the lead from day one) switched teams or left the company over the last five years. Unfortunately I don’t think 27% turnover per year is unusually high in tech, so ownership isn’t a good replacement for written records.

Macha 4y ago

I work on several legacy codebases which were: - written by people who were not me - written by people who have since left the company - the original documentation has rotted away through wiki replacements, issue tracker replacements, or being lost via people turnover or system replacement. The result in many cases is the code is the _only_ documentation of the system behaviour, so seeing what was introduced together is important context to understanding why it is the way it is. I probably run git blame more than git commit at this point and there's a real QoL difference between the good commit messages and the "changes for ticket12345" commit messages.

tsimionescu 4y ago

If you have never needed to find out why a particular piece of code is the way it is, then you have been very lucky to work in very clean code bases. In my own experience, this has been an infrequent but inevitable part of work - maybe once a month or so, I have had to understand whether a particular piece of code, that seems wrong, had a good reason for existing or not. Sometimes it turned out to be a mistake in the original commit, or working around a limitation that no longer exists, other times it has saved me from re-introducing a bug that someone had spent effort fixing.

kazinator 4y ago
ArrayBoundCheck didn't say they never had to find out why a particular piece of code is the way it is, just that they didn't have to search through log messages. For isntance, when you use "git blame" and similar tools, the log messages are not involved. You might end up reading the log message of the commit that was responsible for a change, but you didn't search log messages to get there. In a project with poor commit messages, they will be of little use; reading them won't produce much value, let a lone searching. Anyway, that seems like the best possible interpretation of the user's comment, anyway.
- yencabulator 4y ago
  tsimionescu didn't say anything about searching the logs. The commit message explains (/should explain) why the commit was made. That is useful even if you arrive at the commit via git blame, bisect, etc.