6 ms·

Not sure there's evidence there. I bet if you look over the vast majority of commit messages you will find that they're "lol fuck" or "whoops". The reality is

Not sure there's evidence there. I bet if you look over the vast majority of commit messages you will find that they're "lol fuck" or "whoops". The reality is that developers convey intent through pull requests and rarely go through a commit log. Most people use commits as "ctrl s", which means commit messages are just some dumb shit in the way of me backing up my files.

michaelmior 4y ago
I disagree that the vast majority of commit messages are you describe. But even if that were the case, I don't think the majority of commit messages being bad would mean they don't matter.
- falcolas 4y ago
  Thought exercise: If comments are often considered harmful because of their lacking quality, why would commit messages be considered helpful when they suffer from similar issues?
  - marcosdumay 4y ago
    One reason is that commit messages do not become stale. Anyway, software development as a whole decided on a pretty stable set of comments that are considered helpful. Commit messages are clearly in there, as well as API elements description.
    - staticassertion 4y ago
      > software development as a whole decided on a pretty stable set of comments that are considered helpful. I have no idea what you're talking about.
  - usrusr 4y ago
    In addition to the staleness argument (which is somewhat countered by its inverse: the good, helpful commit message might be hidden under a huge layer of naming convention changes and the like), there's also the off by default. A comment always helps itself to some mental bandwidth, whereas the commit is nicely tidied away unless you ask for it.
- mmcdermott 4y ago
  Descriptively, I do find the default level of rigor to commit messages to be low. Even in repos with really good messages, it is an act of discipline to get them that way and keep them that way. And if there is anything we should all be able to agree on, it's that strong discipline is not the norm in software development as a whole. Note I'm not arguing for that as a prescriptive state. I think a good commit log is a good thing and can see that there are different ways of getting there.
- staticassertion 4y ago
  > I disagree that the vast majority of commit messages are you describe. Sorry but I feel like you have to be just in denial then. > But even if that were the case, I don't think the majority of commit messages being bad would mean they don't matter. OK but I think if it's the case it's fair to say hte majority of developers don't agree, whereas you stated it was an industry wide opinion that they are. I think commit messages are mostly stupid and the git UX is absolute trush. Theoretically, if the git UX weren't trash, they could matter, but it is so they don't.
  - michaelmior 4y ago
    > you stated it was an industry wide opinion I never claimed to be stating an industry-widr opinion. I was disagreeing based on my own personal experience. Based on upvotes and other comments, it seems I am not alone in this opinion.
masklinn 4y ago
> The reality is that developers convey intent through pull requests They really don’t. That doesn’t mean they convey it through commit messages either, mind. But the latter is definitely the worse sin. Having the information in the commit message is much easier to access (especially with a good editor), and it’s way less likely to be lost. PR discussions are often a trawling mess of historical baggage, if something has been discussed back and forth for 6 months I’m generally a lot more interested in a final summary of the whats and the whys, than having to go through the entire thing every time. That’s why the NTSB produces reports, they don’t just publish thousands of hours of raw investigation footwork.
groestl 4y ago
Well, that's how the commit messages in my feature branch look like. It's nothing like the commit message that will end up in the main branch, which usually fills half a terminal page.
foobarian 4y ago
At work, there are a lot of trivial commits, and I don't mind. What I do mind is if something breaks, I go looking at commits, and there are no ticket numbers or other tracking info mentioned in the commit or merge request.
- wizofaus 4y ago
  Pre-commit hooks - most places I've worked at (including open source projects) require you to tag the ticket/issue number.
  - smegsicle 4y ago
    does this discourage opportunistic code cleanup?
    - wizofaus 4y ago
      I discourage that, unless it's very minor! Major code cleanup gets its own ticket. But if it's just fixing a minor spelling issue etc. then no, why would requiring the ticket number to be in the commit be an issue?
tuetuopay 4y ago
> Not sure there's evidence there. I bet if you look over the vast majority of commit messages you will find that they're "lol fuck" or "whoops". Yeah the Linux Kernel tree is _littered_ with those, it's a real pain /s. To be more serious, any workflow that's a tiny bit serious about technical debt will plain reject a PR that's littered with those. I have no problem with rejecting a PR with obvious commits like those. In a professional setting it's vital to keep codebases manageable, especially if those are in the tens. > The reality is that developers convey intent through pull requests and rarely go through a commit log. Not really. Pull request are usually a 1:1 mapping with an user story / ticket id / bug id, etc. They might require multiple changes in multiple places with their own reasoning.
- staticassertion 4y ago
  lol the linux kernel also uses mailing lists

michaelmior 4y ago

I disagree that the vast majority of commit messages are you describe. But even if that were the case, I don't think the majority of commit messages being bad would mean they don't matter.

falcolas 4y ago
Thought exercise: If comments are often considered harmful because of their lacking quality, why would commit messages be considered helpful when they suffer from similar issues?
- marcosdumay 4y ago
  One reason is that commit messages do not become stale. Anyway, software development as a whole decided on a pretty stable set of comments that are considered helpful. Commit messages are clearly in there, as well as API elements description.
  - staticassertion 4y ago
    > software development as a whole decided on a pretty stable set of comments that are considered helpful. I have no idea what you're talking about.
- usrusr 4y ago
  In addition to the staleness argument (which is somewhat countered by its inverse: the good, helpful commit message might be hidden under a huge layer of naming convention changes and the like), there's also the off by default. A comment always helps itself to some mental bandwidth, whereas the commit is nicely tidied away unless you ask for it.
mmcdermott 4y ago
Descriptively, I do find the default level of rigor to commit messages to be low. Even in repos with really good messages, it is an act of discipline to get them that way and keep them that way. And if there is anything we should all be able to agree on, it's that strong discipline is not the norm in software development as a whole. Note I'm not arguing for that as a prescriptive state. I think a good commit log is a good thing and can see that there are different ways of getting there.
staticassertion 4y ago
> I disagree that the vast majority of commit messages are you describe. Sorry but I feel like you have to be just in denial then. > But even if that were the case, I don't think the majority of commit messages being bad would mean they don't matter. OK but I think if it's the case it's fair to say hte majority of developers don't agree, whereas you stated it was an industry wide opinion that they are. I think commit messages are mostly stupid and the git UX is absolute trush. Theoretically, if the git UX weren't trash, they could matter, but it is so they don't.
- michaelmior 4y ago
  > you stated it was an industry wide opinion I never claimed to be stating an industry-widr opinion. I was disagreeing based on my own personal experience. Based on upvotes and other comments, it seems I am not alone in this opinion.

masklinn 4y ago

> The reality is that developers convey intent through pull requests They really don’t. That doesn’t mean they convey it through commit messages either, mind. But the latter is definitely the worse sin. Having the information in the commit message is much easier to access (especially with a good editor), and it’s way less likely to be lost. PR discussions are often a trawling mess of historical baggage, if something has been discussed back and forth for 6 months I’m generally a lot more interested in a final summary of the whats and the whys, than having to go through the entire thing every time. That’s why the NTSB produces reports, they don’t just publish thousands of hours of raw investigation footwork.

groestl 4y ago

Well, that's how the commit messages in my feature branch look like. It's nothing like the commit message that will end up in the main branch, which usually fills half a terminal page.

foobarian 4y ago

At work, there are a lot of trivial commits, and I don't mind. What I do mind is if something breaks, I go looking at commits, and there are no ticket numbers or other tracking info mentioned in the commit or merge request.

wizofaus 4y ago
Pre-commit hooks - most places I've worked at (including open source projects) require you to tag the ticket/issue number.
- smegsicle 4y ago
  does this discourage opportunistic code cleanup?
  - wizofaus 4y ago
    I discourage that, unless it's very minor! Major code cleanup gets its own ticket. But if it's just fixing a minor spelling issue etc. then no, why would requiring the ticket number to be in the commit be an issue?

tuetuopay 4y ago

> Not sure there's evidence there. I bet if you look over the vast majority of commit messages you will find that they're "lol fuck" or "whoops". Yeah the Linux Kernel tree is _littered_ with those, it's a real pain /s. To be more serious, any workflow that's a tiny bit serious about technical debt will plain reject a PR that's littered with those. I have no problem with rejecting a PR with obvious commits like those. In a professional setting it's vital to keep codebases manageable, especially if those are in the tens. > The reality is that developers convey intent through pull requests and rarely go through a commit log. Not really. Pull request are usually a 1:1 mapping with an user story / ticket id / bug id, etc. They might require multiple changes in multiple places with their own reasoning.

staticassertion 4y ago
lol the linux kernel also uses mailing lists