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 git 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.)

Examples of good commit messages are 5c1628e6 or 73d77106.

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.)

Standard prefixes

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 can use git log --oneline path/to/file/or/dir.

Examples for “subsystems” are:

  • Hooks for hook-related changes
  • Bootloader, Bootloader build for the bootloader or it’s build system
  • depend for the dependency detection parts (PyInstaller/depend)
  • building for the building part (PyInstaller/building)
  • compat for code related to compatibility of different Python versions (primary PyInstaller/
  • loader
  • utils, utils/hooks
  • Tests, Test/CI: For changes to the test suite (incl. requirements), resp. the CI.
  • modulegraph: changes related to PyInstaller/lib/modulegraph
  • Doc, Doc build for the documentation content resp. it’s build system. You may want to specify the chapter or section too.

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. Example:

# Set name and email
git config --global "Firstname Lastname"
git config --global ""

This will set this name and email-address to be used for all git-repos you are working on on this system. To set it for just the PyInstaller repo, remove the --global flag.

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 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 gui makes committing selected parts and even selected lines easy. Try the context menu within the windows diff area.

Further Reading

Further hints and tutorials about writing good commit messages can also be found at: