I plead guilty :) I already try to follow these instructions but I tend to forget! Do you have some recent examples? Cheers, Jonathan 2015-09-23 9:29 GMT+01:00 Colin Campbell <colin.campbell@ptfs-europe.com>:
Hi, can I humbly suggest that we should take a couple of secs to make the commit messages for submitted patches a bit more useful. When looking at the history of the code its useful if the summary gives a brief indication of what has been changed or added by the commit. Good summaries can save a lot of frustrated time wasting when trying to track down where a change has been introduced. Although we flag up the bugzilla bug in the summary, just echoing the bug summary is nearly always counter-productive. The commit should indicate the change introduced not the bug that prompted it. Once the patch is applied the original bug is "background reading" not the main event. It is also misleading if the commit summary says "X is broken" then when that is extracted into the release notes or the gitlog it looks like the commit introduces the breakage of x not vice-versa. It is surely better to have the commit say something along the lines of "Fix broken behaviour in X", which makes it sound a bit more like the desirable feature it no doubt is.
A long standing succinct post on commit messages is
http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
Colin (Author of some of the world's worst commit messages)
-- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 800 756 6803 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2
http://www.ptfs-europe.com _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/