2 ms·

What information in the concise version I gave is missing, that causes you to go through additional effort? I think you edited this in after my reply: > If th

What information in the concise version I gave is missing, that causes you to go through additional effort? I think you edited this in after my reply: > If the information took you a great deal of effort to get, that suggests it may be valuable to share. I think this is the core of where we disagree. I often spend insane amounts of time debugging something, only to find the solution was quite simple and unrelated to what I tried. Often the amount of time you spent debugging is because the search space for your solution was unbounded, not because each step you took was particularly relevant to the actual solution. To me a commit message should be able hopefully narrowing that search space, not documenting the original unbounded one.

JoshTriplett 7y ago
I'm not suggesting that the version you gave would be a problem in practice; I'm also not suggesting that the commit message in the article is the best possible commit message for that change. I'm suggesting that after a long debugging adventure, I'd prefer to err on the side of including any information that feels hard-won, rather than trying to make the message as concise as possible at the possible expense of missing an important detail. I've read many commit messages with too little detail, and zero with too much detail. (I have read code with too many comments, but it's rare; I've never once read a commit message that made me think "too much detail".) I'm sure it's possible, but on balance I prefer to cultivate instincts of "document anything that was hard to learn" and "in the moment, prefer to over-document rather than under-document".
- BoorishBears 7y ago
  Isn’t this exactly what I said in my original comment... I appreciate the intention and wouldn’t complain, it’s just if you care enough to write so much, save yourself sometime and the next person to read it some effort by being a little more concise. Commit messages are like naming things, there’s no right way, but the more you try to do it “right” the more “right” you get. If you just throw your hands up and say “I’m goin to vomit our every thought I had working on this”, sure it won’t kill anyone and it’s preferable to always writing nothing (that’s kind of obvious...), but you’ll never get to the point where writing even somewhat balanced messages is comfortable

JoshTriplett 7y ago

I'm not suggesting that the version you gave would be a problem in practice; I'm also not suggesting that the commit message in the article is the best possible commit message for that change. I'm suggesting that after a long debugging adventure, I'd prefer to err on the side of including any information that feels hard-won, rather than trying to make the message as concise as possible at the possible expense of missing an important detail. I've read many commit messages with too little detail, and zero with too much detail. (I have read code with too many comments, but it's rare; I've never once read a commit message that made me think "too much detail".) I'm sure it's possible, but on balance I prefer to cultivate instincts of "document anything that was hard to learn" and "in the moment, prefer to over-document rather than under-document".

BoorishBears 7y ago
Isn’t this exactly what I said in my original comment... I appreciate the intention and wouldn’t complain, it’s just if you care enough to write so much, save yourself sometime and the next person to read it some effort by being a little more concise. Commit messages are like naming things, there’s no right way, but the more you try to do it “right” the more “right” you get. If you just throw your hands up and say “I’m goin to vomit our every thought I had working on this”, sure it won’t kill anyone and it’s preferable to always writing nothing (that’s kind of obvious...), but you’ll never get to the point where writing even somewhat balanced messages is comfortable