3 ms·
Recently, I try to write the first line of my commit messages so they describe what the system now does, compared to before the commit. This makes reading the h
by struppi 10y ago
Recently, I try to write the first line of my commit messages so they describe what the system now does, compared to before the commit. This makes reading the history much more fun. Like:
Validation of email addresses now sends a test email to the user, instead of the old regex that never worked.
This style does not work for all kinds of changes, but when it works, it creates a nice history of how the functionality of the system grew...
- 345678545678655 10y agoLooks too long to me, will end up looking bad in most things.
- TheDong 10y agoIncluding the old bit is meaningless noise there. I'd use something like "Improve email validation" or "email: send a test email as validation" or such. The body is where you can describe previous behaviour and give more details.
- Cthulhu_ 10y agoYeah that. I'd have it describe what the commit does in the subject, and both the why and how in the body: Validation of email addresses now sends a test email to the user, instead of the old regex that never worked. > Send test email to user for email address validation > > This change was done because the old regex never worked; see also {link} and {link} for more information. as an example. Ideally the header also contains a hint to the module the change was done in, etc. The linux kernel commits take this to (what comes across to me as) the highest levels.