8 ms·

I think I would prefer this style. And also the discourse around commit messages and their various flavors may be one of the biggest wastes of time in terms of

I think I would prefer this style. And also the discourse around commit messages and their various flavors may be one of the biggest wastes of time in terms of ROI in our industry. I’ve been doing this for 14-15 years and can probably count on two hands the number of times I’ve needed to look at historical commit messages.

naavis 3y ago
I don't know, I do it almost daily. So your mileage may vary.
- sverhagen 3y ago
  I do it almost daily too. What _is_ rare, is finding a commit message that tells me anything useful that I couldn't have derived from the diff also. I don't need your life story, but sometimes some context about why something was needed is great.
  - rco8786 3y ago
    Exactly. Im in git history all the time. But the messages themselves…eh. Im basically always looking for a change in a specific file or set of files, and then I just pull up the diffs.
  - madeofpalk 3y ago
    What I do find useful is the subject/area, and the author.
  - hmeh 3y ago
    Author here. Yes, the diff should tell you more, but you shouldn't need to look at the diff until you have an idea what the contents of that diff are about. It's like the links on the hacker news home page -- clicking them will always tell you more, but the index should be geared for the use case, which is scanning, typically.
    - sverhagen 3y ago
      I'm not sure that suits everyone's most common use case. (I'm not arguing that it may well suit yours.) I guess on paper it makes sense that commit messages are the top-level entry point to changes. But since we're packaging up a lot of our work in merge requests, the commit messages already get snowed under. Folks arrive in a merge request, and often can't care less about the commit messages that make up the merge request, they may read the message on the merge request, familiarize themselves (ideally) with the story in (ugh) Jira, and then jump to the diff for the review they came there to do. It's the later version of you that is browsing through the code base and wants to understand how a certain current piece of code came about, who then clicks on the gutter in, let's say, IntelliJ, and clicks through to the commit, where both the diff and the commit message are shown.
      - hmeh 3y ago
        Indeed, and since we don’t do pull requests (we pair, mob, and/or do live code reviews), the after-the-fact git blame or the git log to see what has changed recently is what tends to matter. I agree that when I did PRs I didn’t tend to care about the commit messages when I was reviewing them, but even when I did do PRs I cared about them later any time I was trying to understand how, why, or who forensically.
- mewpmewp2 3y ago
  It is so odd to me as I don't remember a single instance during my 10 years of experience having done that. Only if I was asked by someone else in the org why something is the way it is have I gone to history to see what the ticket number is for the referred change to get an explanation and this is more related to the product. I wonder what is so different about our workflows, that some people do it all the time and others almost never. Are we working on somehow very different things. To me I find that code is the source of truth and current state, it doesn't really matter to me as much why or how something came to be as I look more into how I can make the current thing work with what I am to do.
  - g-b-r 3y ago
    Maybe you don't debug bugs? Work on recent and clean codebases? Or simply the projects you work with have poor commit messages?
    - mewpmewp2 3y ago
      I do, and I also work on legacy systems. It just never occurs to me that commit history would somehow help me instead of just looking at the current state of the code. I would say however that the commit messages mostly are just squashed pull requests with ticket names and single sentence so I'd agree that they wouldn't be very good for that purpose, but I don't see anyone at the org complaining about this. It's mostly on the Internet I read how others use the git history, but I haven't seen anyone really doing a lot of that in real life.
      - avgcorrection 3y ago
        > I would say however that the commit messages mostly are just squashed pull requests with ticket names and single sentence so I'd agree that they wouldn't be very good for that purpose, but I don't see anyone at the org complaining about this. There’s your answer.
        g-b-r 3y ago
marginalia_nu 3y ago
It does sort of feel a bit cargo culty sometimes. I expect commit messages are situationally important, as a function of the size and maturity of the project, the size of the development team (esp. the amount of developer churn). That said, there's probably some fringe benefit to describing what you do in some fashion. It's a great way of making sure you understand what's happening yourself.
- avgcorrection 3y ago
  Maybe version control is a cargo cult, then? You might as well just make commits without commit messages if the revision comment is useless. Maybe just squash all commits between versions so you just have one commit per version.
  - marginalia_nu 3y ago
    This is a demonstrably faulty conclusion. Even without commit messages, version control lets you do things that you would not be able to do otherwise, such as to roll back a failed refactoring attempt, for example.
    - avgcorrection 3y ago
      That is very possible to do. People overwrite their save data or their files without any VCS getting in the way. It’s not like you need the history (is this a refactor or something else? doesn’t matter) so you don’t need to keep around such failed attempts.
      - marginalia_nu 3y ago
        It's still a substantial improvement to have known snapshots of the state of the code. It doesn't have to be in VCS, like you can roll it old school and save full zips of the code base, but snapshots are a tangible benefit that VCS offers that does not hinge in the slightest upon well written commit messages.
- 3y ago
azornathogron 3y ago
I look at past commits probably every week or two to track down why something is the way it currently is. Having said that, I care very little about style and grammar of commit messages. Ideally I want them to say why the change was made, what the intended effect was, and where I can look for related work (bugs that tracked the work and have related commits or investigation attached to them, docs, whatever) Hit rate on the information I'd like is not great, but if I get at least one of the three things then it's something I can work with.
- w0m 3y ago
  I'd say I look at commits ~weekly, especially when trying to understand 'WTF did he do that?' - context of tracing the commits (and offtimes back to individual PR when commit is poorly formatted) is valuable.
tsimionescu 3y ago
I personally look more often at past commits, but I've still never really had a need to scan a list of changes like this. I really don't see the point of the advantage they're claiming, even if it's real. What I normally do is, while investigating a tricky bug and finding some lines that don't make sense, look through history to see why those lines were introduced (to see if they fix something else), and perhaps when (to see which versions may be affected by a hard-to-reproduce bug). But that typically pinpoint a commit already, and I just need the commit message to explain why it was there.
safety1st 3y ago
What's tremendously useful for us to have in the commit message, is the ticket ID the work is related to in our issue management system, to the point where it is practically mandatory. I see it as a matter of scoping communications. The issue management system includes a broader set of people than the git repo. You want the commit linked to the issue so that you can see the entire history behind the commit, including the business decisions, the designer making a call, the back and forth with QA etc. That can all be useful a year or two down the road if you want to understand why something was done a certain way. Now there is some info about the change that perhaps only the devs would ever care about, and probably that can sit in the commit messages. That sort of happens naturally but there's not really a lot of it for us. But that seems to me to be the relevant thing from an organizational perspective, no one writes commit messages except for devs, and almost nobody except the devs reads them.
- Scubabear68 3y ago
  This is what I came here to say. Assuming the team is working from JIRA or something, put the ticket number in the commit message. The ticket itself is where your “why” goes.
  - jrs235 3y ago
    I wonder if Atlassian encourages and sells this as an ideal use case [for JIRA]. What a great way to make it really painful to leave their system if in order to make sense of your repo history you to need to maintain the references to their system. They are making your repo dependent on their ticket system...
  - mook 3y ago
    It's really nice to have the actual reasoning in the commit history though. But maybe I was just scarred by the project that switched project management software like 5 times over its lifetime (but kept all of the commits) though.
    - aaronbrethorst 3y ago
bob1029 3y ago
Blame & diffs are much more useful to me in the context of GitHub. I don't care about someone's subjective ~50 char description of a change. The important part is the pull request itself and that it references whatever issue prompted the change. Commit messages have only ever been useful in tracking my own intermediate work products. Often times, I will leave helpful bread crumbs in my commit notes if I know I won't be working on something for a few days. We strictly do squash+merge, so I don't have to worry about these things causing trouble for others. All of our commits into master have some standardized "Issue #1234" note as automatically copied from the PR title (which we do have ~standardized). If we didnt have some git wrapper like GitHub available, then I suspect we'd be significantly more aggressive with policy around our commit messages.
- g-b-r 3y ago
  If your process requires trashing the commit messages it's not surprising you don't find them useful.
lucb1e 3y ago
<10 instances of looking at the commit history in >10 years is exceptionally little. I think you may have a different use-case if your commits are write-only and crafting commit message texts is probably a waste of time at that rate Which is a very interesting take, for what it's worth. Might be worth a blog post what circumstances lead to this working well for your organization!

naavis 3y ago

I don't know, I do it almost daily. So your mileage may vary.

sverhagen 3y ago
I do it almost daily too. What _is_ rare, is finding a commit message that tells me anything useful that I couldn't have derived from the diff also. I don't need your life story, but sometimes some context about why something was needed is great.
- rco8786 3y ago
  Exactly. Im in git history all the time. But the messages themselves…eh. Im basically always looking for a change in a specific file or set of files, and then I just pull up the diffs.
- madeofpalk 3y ago
  What I do find useful is the subject/area, and the author.
- hmeh 3y ago
  Author here. Yes, the diff should tell you more, but you shouldn't need to look at the diff until you have an idea what the contents of that diff are about. It's like the links on the hacker news home page -- clicking them will always tell you more, but the index should be geared for the use case, which is scanning, typically.
  - sverhagen 3y ago
    I'm not sure that suits everyone's most common use case. (I'm not arguing that it may well suit yours.) I guess on paper it makes sense that commit messages are the top-level entry point to changes. But since we're packaging up a lot of our work in merge requests, the commit messages already get snowed under. Folks arrive in a merge request, and often can't care less about the commit messages that make up the merge request, they may read the message on the merge request, familiarize themselves (ideally) with the story in (ugh) Jira, and then jump to the diff for the review they came there to do. It's the later version of you that is browsing through the code base and wants to understand how a certain current piece of code came about, who then clicks on the gutter in, let's say, IntelliJ, and clicks through to the commit, where both the diff and the commit message are shown.
    - hmeh 3y ago
      Indeed, and since we don’t do pull requests (we pair, mob, and/or do live code reviews), the after-the-fact git blame or the git log to see what has changed recently is what tends to matter. I agree that when I did PRs I didn’t tend to care about the commit messages when I was reviewing them, but even when I did do PRs I cared about them later any time I was trying to understand how, why, or who forensically.
mewpmewp2 3y ago
It is so odd to me as I don't remember a single instance during my 10 years of experience having done that. Only if I was asked by someone else in the org why something is the way it is have I gone to history to see what the ticket number is for the referred change to get an explanation and this is more related to the product. I wonder what is so different about our workflows, that some people do it all the time and others almost never. Are we working on somehow very different things. To me I find that code is the source of truth and current state, it doesn't really matter to me as much why or how something came to be as I look more into how I can make the current thing work with what I am to do.
- g-b-r 3y ago
  Maybe you don't debug bugs? Work on recent and clean codebases? Or simply the projects you work with have poor commit messages?
  - mewpmewp2 3y ago
    I do, and I also work on legacy systems. It just never occurs to me that commit history would somehow help me instead of just looking at the current state of the code. I would say however that the commit messages mostly are just squashed pull requests with ticket names and single sentence so I'd agree that they wouldn't be very good for that purpose, but I don't see anyone at the org complaining about this. It's mostly on the Internet I read how others use the git history, but I haven't seen anyone really doing a lot of that in real life.
    - avgcorrection 3y ago
      > I would say however that the commit messages mostly are just squashed pull requests with ticket names and single sentence so I'd agree that they wouldn't be very good for that purpose, but I don't see anyone at the org complaining about this. There’s your answer.
      - g-b-r 3y ago

marginalia_nu 3y ago

It does sort of feel a bit cargo culty sometimes. I expect commit messages are situationally important, as a function of the size and maturity of the project, the size of the development team (esp. the amount of developer churn). That said, there's probably some fringe benefit to describing what you do in some fashion. It's a great way of making sure you understand what's happening yourself.

avgcorrection 3y ago
Maybe version control is a cargo cult, then? You might as well just make commits without commit messages if the revision comment is useless. Maybe just squash all commits between versions so you just have one commit per version.
- marginalia_nu 3y ago
  This is a demonstrably faulty conclusion. Even without commit messages, version control lets you do things that you would not be able to do otherwise, such as to roll back a failed refactoring attempt, for example.
  - avgcorrection 3y ago
    That is very possible to do. People overwrite their save data or their files without any VCS getting in the way. It’s not like you need the history (is this a refactor or something else? doesn’t matter) so you don’t need to keep around such failed attempts.
    - marginalia_nu 3y ago
      It's still a substantial improvement to have known snapshots of the state of the code. It doesn't have to be in VCS, like you can roll it old school and save full zips of the code base, but snapshots are a tangible benefit that VCS offers that does not hinge in the slightest upon well written commit messages.
3y ago

azornathogron 3y ago

I look at past commits probably every week or two to track down why something is the way it currently is. Having said that, I care very little about style and grammar of commit messages. Ideally I want them to say why the change was made, what the intended effect was, and where I can look for related work (bugs that tracked the work and have related commits or investigation attached to them, docs, whatever) Hit rate on the information I'd like is not great, but if I get at least one of the three things then it's something I can work with.

w0m 3y ago
I'd say I look at commits ~weekly, especially when trying to understand 'WTF did he do that?' - context of tracing the commits (and offtimes back to individual PR when commit is poorly formatted) is valuable.

tsimionescu 3y ago

I personally look more often at past commits, but I've still never really had a need to scan a list of changes like this. I really don't see the point of the advantage they're claiming, even if it's real. What I normally do is, while investigating a tricky bug and finding some lines that don't make sense, look through history to see why those lines were introduced (to see if they fix something else), and perhaps when (to see which versions may be affected by a hard-to-reproduce bug). But that typically pinpoint a commit already, and I just need the commit message to explain why it was there.

safety1st 3y ago

What's tremendously useful for us to have in the commit message, is the ticket ID the work is related to in our issue management system, to the point where it is practically mandatory. I see it as a matter of scoping communications. The issue management system includes a broader set of people than the git repo. You want the commit linked to the issue so that you can see the entire history behind the commit, including the business decisions, the designer making a call, the back and forth with QA etc. That can all be useful a year or two down the road if you want to understand why something was done a certain way. Now there is some info about the change that perhaps only the devs would ever care about, and probably that can sit in the commit messages. That sort of happens naturally but there's not really a lot of it for us. But that seems to me to be the relevant thing from an organizational perspective, no one writes commit messages except for devs, and almost nobody except the devs reads them.

Scubabear68 3y ago
This is what I came here to say. Assuming the team is working from JIRA or something, put the ticket number in the commit message. The ticket itself is where your “why” goes.
- jrs235 3y ago
  I wonder if Atlassian encourages and sells this as an ideal use case [for JIRA]. What a great way to make it really painful to leave their system if in order to make sense of your repo history you to need to maintain the references to their system. They are making your repo dependent on their ticket system...
- mook 3y ago
  It's really nice to have the actual reasoning in the commit history though. But maybe I was just scarred by the project that switched project management software like 5 times over its lifetime (but kept all of the commits) though.
  - aaronbrethorst 3y ago

bob1029 3y ago

Blame & diffs are much more useful to me in the context of GitHub. I don't care about someone's subjective ~50 char description of a change. The important part is the pull request itself and that it references whatever issue prompted the change. Commit messages have only ever been useful in tracking my own intermediate work products. Often times, I will leave helpful bread crumbs in my commit notes if I know I won't be working on something for a few days. We strictly do squash+merge, so I don't have to worry about these things causing trouble for others. All of our commits into master have some standardized "Issue #1234" note as automatically copied from the PR title (which we do have ~standardized). If we didnt have some git wrapper like GitHub available, then I suspect we'd be significantly more aggressive with policy around our commit messages.

g-b-r 3y ago
If your process requires trashing the commit messages it's not surprising you don't find them useful.

lucb1e 3y ago

<10 instances of looking at the commit history in >10 years is exceptionally little. I think you may have a different use-case if your commits are write-only and crafting commit message texts is probably a waste of time at that rate Which is a very interesting take, for what it's worth. Might be worth a blog post what circumstances lead to this working well for your organization!