[Bf-committers] Guidelines to format commit logs

GSR gsr.b3d at infernal-iceberg.com
Sat Nov 16 23:51:15 CET 2013


Hi,
brechtvanlommel at pandora.be (2013-11-15 at 2039.00 +0100):
> Sending a reminder for after the switch to git, we have guidelines for
> how to format your commit logs to keep it all easy to scan quickly,
> understand for users and turn into release notes.
> 
> The wiki page with guidelines is here:
> http://wiki.blender.org/index.php/Dev:Doc/New_Committer_Info#Commit_Logs

Will Blender follow the git standards of first short line summary
followed, if needed, by a blank line and extra explanations, and
limiting the number of columns in logs?

git doesn't complain if you don't, but you don't get nice output
either then, it's assumed the logs are git style. Examples of tools
that depend in that for better/proper results are git log
--pretty=oneline (or short) for the first line having proper meaning
on itself, gitweb for the column limits (the blender one is already
showing huge side scrolling).

There is plenty of talk and examples about this:
http://ablogaboutcode.com/2011/03/23/proper-git-commit-messages-and-an-elegant-git-history/
https://wiki.openstack.org/wiki/GitCommitMessages
http://gitref.org/basic/#commit
https://www.kernel.org/pub/software/scm/git/docs/user-manual.html#creating-good-commit-messages

Luckly compared to SVN, this time some checks can be done via hooks,
instead of having to pest everyone by email and then getting ignored
anyway. Or by using pulls by someone after reviewing, instead of
pushing by everyone without control.

What is more, now with git there is no excuse for huge commits or
commits that mix different things like improvements and fixes, or
things from different topics. Changes can be organized logically, in
small steps. But people must do that right to begin, or follow the
pull approach so master is clean.

GSR
 


More information about the Bf-committers mailing list