The preferred is to email patches to the thg-devel mailing list. If possible, please don't attach your patches, but use the patchbomb extension (or "Email Patch" of TortoiseHg) instead.
For trivial changes, pull requests are also accepted.
You should indicate to which branch your patch applies (stable or default). Bug fix patches should be based on stable unless the bug they address is only on the default branch.
The Mercurial wiki has a good page with suggestions for contributing patches. In general these are also applicable for TortoiseHg.
TortoiseHg specific guidelines can be found in CONTRIBUTING.txt
Please also note that TortoiseHg has adopted the unix line end style of the Mercurial sources, even though we are targeting the Windows platform.
Guidelines For Commit Messages
- If your change is in response to an issue in the bug tracker, you should use trac style commands in your commit message:
- Make sure your commit message starts with a reasonable one-line summary.
- Keep all lines, especially the summary line, below 80 (72 preferred) characters.
- If you are going to give more detail in the commit message, please keep a blank line below the summary line, right before the start of the detail.
- Prefix the commit summary with a short text identifying the area the patch is targeting (see below).
- We prefer no capitalization in the summary line, unless required by quoted variable or file names.
Here's some examples by peso to help illustrate the guidelines:
The standard prefixes we've used so far (extracted from the revision history) :
- cmenu - context menu extension
- <module> - changes made to <module> in tortoisehg/hgqt/ subdir
- wix - on binary installer (WiX, config files, etc)
- setup - changes in setup.py
- icons - icon maintenance
- doc - contributions to the documentation
- nautilus - nautilus integration
Please note that there's no standard per se, just use your common sense if you encounter a new area, or even revise an existing one. Please refer to the changelog of TortoiseHg if in doubt, or consult the mailing lists.
The general idea is to be able to identify the areas that a patch targets, while consuming the minimum amount of characters on the summary line.