Development Commit Messages
Clone this wiki locally
Format of the commit message
The first line of the commit message should be a short summary that can stand alone as a short description of the change.
This may optionally be followed by a separating blank line and details in whatever form the commenter likes.
Try to end summary lines with a period. Ending punctuation other than a period should be used to indicate that the summary line is incomplete and continues after the separator; "..." is conventional.
For best results, stay within 72 characters per line. Don't go over 80.
Write your commit message in the present tense: "Fix bug" and not "Fixed bug." Consider these messages as the instructions for what applying the commit will do. Further this convention matches up with commit messages generated by commands like git merge and git revert.
If you find yourself describing implementation details, this most probably should go into a source code comment.
Consider including motivation for the change, and contrasts its implementation with previous behaviour.
Bullet points are okay, too:
* Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here * Use a hanging indent.
- Do not start your commit message with a hash-mark (
#) as git some git commands may dismiss these message. (See this discussion for details.)
Please use one of our standard prefixes for the subject:
Add:for new feature without a bug report
Fix:for small fixes without a bug report
Enh:for enhancement without a bug report
Issue #1234:Modifications related to a issue. Use "Issue" instead of "Ticket", this saves one character :-)
Clean:for modifications improving code structure, not changing !PyInstaller functionality
Please set the correct Author
Please make sure you have setup git to use the correct name and email for your commits. Use the same name and email on all machines you may push from.
# Set the name of the user for all git instances on the system git config --global user.name "Firstname Lastname" # Set the email-address of the user for all git instances on the system git config --global user.email "email@example.com"
This will set your name and email globally. To set it for just the PyInstaller repo, remove the
Alternatively you may use
git gui -> Edit -> Options ... to set these values.
How to write good commit messages
The following is an excerpt from the FreeBSD Committer's Guide and sums up quite nicely what I think:
Good commit messages are important. They tell others why you did the changes you did, not just right here and now, but months or years from now when someone wonders why some seemingly illogical or inefficient piece of code snuck into your source file. It is also an invaluable aid to deciding which changes to merge from the -CURRENT branch to -STABLE and which not.
Commit messages should be clear, concise and provide a reasonable summary to give an indication of what was changed and why.
Commit messages should provide enough information to enable a third party to decide if the change is relevant to them and if they need to read the change itself.
Avoid committing several unrelated changes in one go. It makes merging difficult, and also makes it harder to determine which change is the culprit if a bug crops up.
Avoid committing style or whitespace fixes and functionality fixes in one go. It makes merging difficult, and also makes it harder to understand just what functional changes were made. In the case of documentation files, it can make the job of the translation teams more complicated, as it becomes difficult for them to determine exactly what content changes need to be translated.
Avoid committing changes to multiple files in one go with a generic, vague message. Instead, commit each file (or small, related groups of files) with tailored commit messages.
If you did several unrelated changes before committing,
git guimakes committing selected parts and even selected lines easy. Try the context menu within the windows diff area.
Further hints and tutorials about writing good commit messages can also be found at
- http://wincent.com/blog/commit-messages: The Good, the Bad and the Ugly.
- http://subversion.apache.org/docs/community-guide/conventions.html (Targeted a bit too much to subversion usage, which doe not use such fine-grained commits as we ask you strongly to use.)
This page was composed from material found at