3,267
edits
Changes
Activity Team/Git Migration (view source)
Revision as of 08:11, 23 January 2009
, 08:11, 23 January 2009→Git commit message guidelines
* Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. Tools that turn commits into email, for example, use the first line on the Subject: line and the rest of the commit in the body. The git-shortlog command the we use to write the release notes will strip the more detailed description.
* Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. Tools that turn commits into email, for example, use the first line on the Subject: line and the rest of the commit in the body. The git-shortlog command the we use to write the release notes will strip the more detailed description.
* If your commit does fix a certain bug make sure that the summarizing line contains the bug number prepended by a '#' at the end of the line (e.g. #14). We
* If your commit does fix a certain bug make sure that the summarizing line contains the bug number prepended by a '#' at the end of the line (e.g. #14). It is implied that you mean the Sugar Labs trac instance. If not please prepend an identifier like OLPC#123 and RH#456.
* Start your commit message with a capital letter.
* Suffix no dot at the end of the summarizing line.
* Fixes for typing errors and pylint fixes happen quite often. Just mark them _Typo and respectively _Pylint for easier reading.