4 ms·

> I don't think anything in the subject or message should be a re-run of the code Well, you're just wrong then. These aren't code comments. They're commit su

> I don't think anything in the subject or message should be a re-run of the code Well, you're just wrong then. These aren't code comments. They're commit summaries. They exist only to answer the question "what?"--tersely. Because they're meant to help you pick out the right one when you're looking at a list of them and don't have the entire diff on the screen. But I don't think we're even in conflict here, because your example ("Fix syntax error[...]") actually shows this. I don't know why you keep calling that "why". It's "what". Any way of thinking of this as answering the question "why" (such as "why am I making this change?") is incidental. You're identifying which commit this is. That's a "what". > Code: ... (that which I've called 'what') What? No, code is never "what", whether you're talking about commits or you actually are working on the code and comments themselves. Code is "how", identifiers/names are "what", and comments and commit messages are "why". See my other reply to Vinnl about how weird it is to mix up "why" and "how" in the same breath.

OJFord 5y ago
Well, I've called it what. The code is what I'm committing; the subject is why I'm committing it; the message is (a continuation of the subject's why and) a description of how I arrived at it, how it applies to the problem, etc. Of course it can be phrased differently ('code is how I'm solving the problem; subject is what problem I'm solving' etc.) - I really don't think it matters much what we call them. Point is that, IMO, the subject especially and to a large extent the rest of the message should focus on the reason for the change, not re-describe the change itself, and framed in a way that's not necessarily end-user oriented but is certainly more detached from the implementation in code. Less ambiguous than what/why/how then: code - the change; subject - the reason for it; message - the explanation of it.

OJFord 5y ago

Well, I've called it what. The code is what I'm committing; the subject is why I'm committing it; the message is (a continuation of the subject's why and) a description of how I arrived at it, how it applies to the problem, etc. Of course it can be phrased differently ('code is how I'm solving the problem; subject is what problem I'm solving' etc.) - I really don't think it matters much what we call them. Point is that, IMO, the subject especially and to a large extent the rest of the message should focus on the reason for the change, not re-describe the change itself, and framed in a way that's not necessarily end-user oriented but is certainly more detached from the implementation in code. Less ambiguous than what/why/how then: code - the change; subject - the reason for it; message - the explanation of it.