Hi, [email protected] (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 _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
