Please Write Good Commit Messages¶
Please help keeping code and changes comprehensible for years. Write good commit messages following this guideline.
PyInstaller is maintained since 2005 and we often need to comprehend years later why a certain change has been implemented as it is. What seemed to be obvious when the change was applied may be just obscure years later. The original contributor may be out if reach, while another developer needs get comprehend the reasons, side-effects and decisions the original author considered.
We learned that commit messages are important to comprehend changes and thus we are a bit picky about them.
We may ask you to reword your commit messages. In this case, use
rebase -i … and
git push -f … to update your pull-request. See
Updating a Pull-Request for details.
Content of the commit message¶
- 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.
- Please include motivation for the change, and contrasts its implementation with previous behavior.
- For more complicate or serious changes please document relevant decisions, contrast them with other possibilities for chosen, side-effect you experienced, or other thinks to keep in mind when touching this peace of code again. (Although the later might better go into a source code comment.)
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.
The first line should start with the “subsystem” this commit is related to, see the list of standard prefixes below.
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.
Bullet points and numbered lists 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 state the “subsystem” this commit is related to as a prefix in the
first line. Do learn which prefixes others used for the files you changed you
git log --oneline path/to/file/or/dir.
Examples for “subsystems” are:
Hooksfor hook-related changes
Bootloader buildfor the bootloader or it’s build system
dependfor the dependency detection parts (
buildingfor the building part (
compatfor code related to compatibility of different Python versions (primary
Test/CI: For changes to the test suite (incl. requirements), resp. the CI.
modulegraph: changes related to
Doc buildfor the documentation content resp. it’s build system. You may want to specify the chapter or section too.
How to write good commit messages¶
The following is an excerpt from the FreeBSD Committer’s Guide and sums up quite nicely what we 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 does not use such fine-grained commits as we ask you strongly to use.)
This page was composed from material found at