4 ms·

On my work I make 1-15 commits a day. If I have to spend thought cycles on the commit message, that is time that goes from other productive endeavours. I think

On my work I make 1-15 commits a day. If I have to spend thought cycles on the commit message, that is time that goes from other productive endeavours. I think, as the original commenter also wrote, this might be worth it in much slower paces projects that is run in another cadence / over mailing lists. I particularly think that high paced application development do not benefit from git as documentation.

floating-io 3y ago
I would argue (rightly or wrongly) that there are two common truths to such a scenario: Scenario 1, you’re doing a bunch of small changes that work towards a larger purpose. They’re what I like to call “checkpoint commits”. They aren’t the whole story —- just a step along the way to whatever you’re trying to accomplish. Scenario 2, you’re coding instead of thinking. Making “random” changes until you get what you want, but because you’re continuously delivering, they all go to production. Note that “you” here might be the developer, or it might be business people demanding things from said developer. In scenario 1, IMO you should be working on a branch. Then, when you’re finished, you squash your commits and replace the countless mini-messages (“fixed”, “Oops”, “wtf?”) with the actual message you want to be there when you merge it. In scenario 2, especially if it’s driven by business, you’re probably SOL. In this instance, however, I tend to feel like people are making more work for themselves. If they stopped and thought it through for half an hour before starting work, it might only take an hour’s worth of work and one commit, instead of a day and thirty commits. Of course, there are always shades in between. :)
- madsbuch 3y ago
  None of these, the granularity of the changes are just smaller. Yes, you could argue that we should go with preview envs and only merge larger changes into main. But then again, this adds considerable complexity to the infrastructure – something that might be merited when we scale to 10+ software engineers. This is the nature of products where you work close with designers, POs, etc. You simply don't don't do this effort to update text, positioning, colors, etc. In particular: Remember that git is _not_ just for kernel-style projects.
jonathanpglick 3y ago
Until it's 7 years later, the original developers are gone, the ticketing system has changed twice, and you have no clue why something is the way it is. When you're committing is exactly when you already have the context of "why" loaded and even a short explanation should be quick to write. The thought cycles argument feels lazy unless you're doing a bunch of quick exploratory commits and clean up/squash your git history later and add context once a solution solidifies.
- madsbuch 3y ago
  In that case, why should the commit history be the place to go? Commit histories are extremely exclusive – everybody not a part of the programming process will be locked out of that information. That is not fair. Regardless, what you describe is more an organisational failure than an issue with commit messages.
  - palata 3y ago
    > In that case, why should the commit history be the place to go? In my experience with open source projects, the history is very much where I go. Say I read some code and don't understand a line (say it is weird, but it does not feel like complete garbage because the rest of the code is actually good), then I will definitely `git blame` or even start digging in the history to see where that line comes from. Good commit messages have saved me more than once in that situation. It doesn't have to be a whole essay, but something meaningful. Something like "apparently Travis CI wants two white spaces here" is already useful: it says that back then, they used a CI called "Travis" and it required that weird extra space. Now I feel safe removing it because the project does not rely on Travis anymore. (For example). Note: it could be in a comment. But comments rot, move, get out of sync, disappear. It's much harder to check all the revisions of a file in the last 7 years to look for a potential comment on another line than it is to find the commits that actually edited the line of code.
tetha 3y ago
> I think, as the original commenter also wrote, this might be worth it in much slower paces projects that is run in another cadence / over mailing lists. Very much this. If I'm modifying some rather obvious and ovreall simple thing like an obvious config of a grafana, adding a customer to a config and such things... it's hard to really bother with a long commit message. Also, with modern tools like VSCode with the Gremlin plugin, I don't think I'd have spent many words on removing a weird whitespace from a code base, to be honest. On the other hand, if I've spent 4 hours thinking and 2 of those hours discussing the change with another DBA changing a 2 into an 8 in the config of an SLA-critical postgres cluster... spending 10 minutes on a commit message in the config management is - with regard to time - a footnote, irrelevant and inconsequential. But it can be worth more than gold down the road if you ask "Why 8? Why not 6!"
sunshowers 3y ago
> On my work I make 1-15 commits a day. If I have to spend thought cycles on the commit message, that is time that goes from other productive endeavours. I make roughly that many commits a day as well. If something's easy to understand I'll put in a simple commit message (e.g. [1]), but I do put in the effort for more complicated ones. [1] https://github.com/nextest-rs/nextest/commit/efd194b2e1d8d615f092d3a4e3d538286d77ec08 https://github.com/nextest-rs/nextest/commit/efd194b2e1d8d61... [2] https://github.com/oxidecomputer/omicron/commit/b07a8f593325efe97ddb526c2725d45d480bf7e6 https://github.com/oxidecomputer/omicron/commit/b07a8f593325...
palata 3y ago
> On my work I make 1-15 commits a day. If I have to spend thought cycles on the commit message, that is time that goes from other productive endeavours. Do you apply that to everything? Like not answering questions from your colleagues, not writing test, not refactoring, not optimizing, etc? I personally don't measure my productivity by the number of commits I push. If I did, I could easily make 100 commits a day. And there of course it would be better for me to not care about the commit description, because it would take thought cycles and anyway the commits would make no sense.
- madsbuch 3y ago
  Like the sibling comment, this comment reads like a person who don't realise the breath of projects git are used for. Not answering questions from my colleagues? No nee to be snarky, lets keep a good tone here. Small refactorings is a good example of some code I would not write long commit messages. Like going through a function improving its clarity and adding comments – I would not redo that effort in the commit message. Text updates, style updates, etc. are also things that rarely merits big messages. Great for you that you don't make 100 commits a day – but watch out that you don't mix disparate changes into a single commit.
  - palata 3y ago
    > Not answering questions from my colleagues? No nee to be snarky, lets keep a good tone here. I didn't mean to be snarky, sorry if I read like that! I was trying to list examples of "non-coding" that I find are important :-). > Small refactorings is a good example of some code I would not write long commit messages. I totally agree! Now I am starting to think that we all agree here. I was just confused because your comment seemed to disagree with its parent, which says: "Sometimes that context fits in the subject line. For others, I expect an elaborate body". But apparently you do agree with that: sometimes it is worth writing a long commit message, sometimes it is not. It depends on the situation, and then it's a matter of common sense/experience.
goku12 3y ago
> If I have to spend thought cycles on the commit message, that is time that goes from other productive endeavours. This is a bad excuse against writing proper commit messages, since it can be easily extended to user and development documentation. If you want to classify these as productive endeavors while commit messages as non-productive, it basically boils down to doing as little as possible that you can get away with. > On my work I make 1-15 commits a day. That is hardly hectic enough to avoid good commit messages. I have seen people writing good commit messages at much higher commit rates. Frankly, good commit messages are actually time savers if you have a high commit rates. > I particularly think that high paced application development do not benefit from git as documentation. Things like good commit messages and a lot of other best practices are completely avoidable in the name of high pace. However, the time savings are marginal compared to the quality you sacrifice.

floating-io 3y ago

I would argue (rightly or wrongly) that there are two common truths to such a scenario: Scenario 1, you’re doing a bunch of small changes that work towards a larger purpose. They’re what I like to call “checkpoint commits”. They aren’t the whole story —- just a step along the way to whatever you’re trying to accomplish. Scenario 2, you’re coding instead of thinking. Making “random” changes until you get what you want, but because you’re continuously delivering, they all go to production. Note that “you” here might be the developer, or it might be business people demanding things from said developer. In scenario 1, IMO you should be working on a branch. Then, when you’re finished, you squash your commits and replace the countless mini-messages (“fixed”, “Oops”, “wtf?”) with the actual message you want to be there when you merge it. In scenario 2, especially if it’s driven by business, you’re probably SOL. In this instance, however, I tend to feel like people are making more work for themselves. If they stopped and thought it through for half an hour before starting work, it might only take an hour’s worth of work and one commit, instead of a day and thirty commits. Of course, there are always shades in between. :)

madsbuch 3y ago
None of these, the granularity of the changes are just smaller. Yes, you could argue that we should go with preview envs and only merge larger changes into main. But then again, this adds considerable complexity to the infrastructure – something that might be merited when we scale to 10+ software engineers. This is the nature of products where you work close with designers, POs, etc. You simply don't don't do this effort to update text, positioning, colors, etc. In particular: Remember that git is _not_ just for kernel-style projects.

jonathanpglick 3y ago

Until it's 7 years later, the original developers are gone, the ticketing system has changed twice, and you have no clue why something is the way it is. When you're committing is exactly when you already have the context of "why" loaded and even a short explanation should be quick to write. The thought cycles argument feels lazy unless you're doing a bunch of quick exploratory commits and clean up/squash your git history later and add context once a solution solidifies.

madsbuch 3y ago
In that case, why should the commit history be the place to go? Commit histories are extremely exclusive – everybody not a part of the programming process will be locked out of that information. That is not fair. Regardless, what you describe is more an organisational failure than an issue with commit messages.
- palata 3y ago
  > In that case, why should the commit history be the place to go? In my experience with open source projects, the history is very much where I go. Say I read some code and don't understand a line (say it is weird, but it does not feel like complete garbage because the rest of the code is actually good), then I will definitely `git blame` or even start digging in the history to see where that line comes from. Good commit messages have saved me more than once in that situation. It doesn't have to be a whole essay, but something meaningful. Something like "apparently Travis CI wants two white spaces here" is already useful: it says that back then, they used a CI called "Travis" and it required that weird extra space. Now I feel safe removing it because the project does not rely on Travis anymore. (For example). Note: it could be in a comment. But comments rot, move, get out of sync, disappear. It's much harder to check all the revisions of a file in the last 7 years to look for a potential comment on another line than it is to find the commits that actually edited the line of code.

tetha 3y ago

> I think, as the original commenter also wrote, this might be worth it in much slower paces projects that is run in another cadence / over mailing lists. Very much this. If I'm modifying some rather obvious and ovreall simple thing like an obvious config of a grafana, adding a customer to a config and such things... it's hard to really bother with a long commit message. Also, with modern tools like VSCode with the Gremlin plugin, I don't think I'd have spent many words on removing a weird whitespace from a code base, to be honest. On the other hand, if I've spent 4 hours thinking and 2 of those hours discussing the change with another DBA changing a 2 into an 8 in the config of an SLA-critical postgres cluster... spending 10 minutes on a commit message in the config management is - with regard to time - a footnote, irrelevant and inconsequential. But it can be worth more than gold down the road if you ask "Why 8? Why not 6!"

sunshowers 3y ago

> On my work I make 1-15 commits a day. If I have to spend thought cycles on the commit message, that is time that goes from other productive endeavours. I make roughly that many commits a day as well. If something's easy to understand I'll put in a simple commit message (e.g. [1]), but I do put in the effort for more complicated ones. [1] https://github.com/nextest-rs/nextest/commit/efd194b2e1d8d615f092d3a4e3d538286d77ec08 https://github.com/nextest-rs/nextest/commit/efd194b2e1d8d61... [2] https://github.com/oxidecomputer/omicron/commit/b07a8f593325efe97ddb526c2725d45d480bf7e6 https://github.com/oxidecomputer/omicron/commit/b07a8f593325...

palata 3y ago

> On my work I make 1-15 commits a day. If I have to spend thought cycles on the commit message, that is time that goes from other productive endeavours. Do you apply that to everything? Like not answering questions from your colleagues, not writing test, not refactoring, not optimizing, etc? I personally don't measure my productivity by the number of commits I push. If I did, I could easily make 100 commits a day. And there of course it would be better for me to not care about the commit description, because it would take thought cycles and anyway the commits would make no sense.

madsbuch 3y ago
Like the sibling comment, this comment reads like a person who don't realise the breath of projects git are used for. Not answering questions from my colleagues? No nee to be snarky, lets keep a good tone here. Small refactorings is a good example of some code I would not write long commit messages. Like going through a function improving its clarity and adding comments – I would not redo that effort in the commit message. Text updates, style updates, etc. are also things that rarely merits big messages. Great for you that you don't make 100 commits a day – but watch out that you don't mix disparate changes into a single commit.
- palata 3y ago
  > Not answering questions from my colleagues? No nee to be snarky, lets keep a good tone here. I didn't mean to be snarky, sorry if I read like that! I was trying to list examples of "non-coding" that I find are important :-). > Small refactorings is a good example of some code I would not write long commit messages. I totally agree! Now I am starting to think that we all agree here. I was just confused because your comment seemed to disagree with its parent, which says: "Sometimes that context fits in the subject line. For others, I expect an elaborate body". But apparently you do agree with that: sometimes it is worth writing a long commit message, sometimes it is not. It depends on the situation, and then it's a matter of common sense/experience.

goku12 3y ago

> If I have to spend thought cycles on the commit message, that is time that goes from other productive endeavours. This is a bad excuse against writing proper commit messages, since it can be easily extended to user and development documentation. If you want to classify these as productive endeavors while commit messages as non-productive, it basically boils down to doing as little as possible that you can get away with. > On my work I make 1-15 commits a day. That is hardly hectic enough to avoid good commit messages. I have seen people writing good commit messages at much higher commit rates. Frankly, good commit messages are actually time savers if you have a high commit rates. > I particularly think that high paced application development do not benefit from git as documentation. Things like good commit messages and a lot of other best practices are completely avoidable in the name of high pace. However, the time savings are marginal compared to the quality you sacrifice.