On Fri, Aug 25, 2017 at 12:37:43PM -0700, Brandon Williams wrote: > > > My knee-jerk reaction is if it's worth writing after the dashes, it's > > > worth putting in the commit message. > > > > > > However, in the case I think it is OK as-is (the motivation of "we > > > already avoid leaking auth info to stdout, so we should do the same for > > > error messages" seems self-contained and reasonable) > > Well, I tend to be wordy, and most of the commit messages I saw were > > rather short, so decided to split. Wonder, if maybe example command > > should be included without the rest of it. Would it be useful? > > I'm guilty of writing short commit messages (something I need to work > on) but when looking through logs I much prefer to see longer messages > explaining rationals and trade-offs. I think as with all writing, there is both "too short" and "too long". I like having those extra bits in the commit message, too, but you have to make sure they don't drown out the main points. I find that when a message gets long, it often benefits from revising and re-ordering. E.g., having an intro paragraph that explains the motivation and solution in one sentence, and _then_ go into the details for people who are really digging into the details. Good organization lets readers get just the level they need and skip the rest. Easier said than done, of course. :) -Peff
