Every commit to Git must be accompanied by a log message. These messages will be generated into a ChangeLog when a release is made and should conform to the following guidelines:
- The first line of the commit message should consist of a short summary of the change.
- If the commit fixes a bug on the bug tracker, the summary shall include the bug ID and summary from the tracker.
- The summary should be separated from the body of the message by a single blank line.
- Messages should attempt to describe how the change affects the functionality from the user's perspective.
- Use complete sentences when possible.
- It is not necessary to describe minute details about the change nor the files that are affected because that information is already stored by Git and can be viewed with "git diff".
- When committing contributed code, the author should be credited using the --author option.
- If you want to refer to another commit, use the commit short hash (6 hexa digits) in square brackets. It will automatically be expanded to a hyperlink by the SourceForge web interface to the repository, e.g.: [d8acf8]. Note: the default short hash in git is 7 hexa digits (as produced by `git log --oneline' command), and that WILL NOT WORK with auto-hyperlinking of sourceforge :-(
You can see the last changes with the git log command, an example usage of this command:
git log --oneline
You can also limit the number of entries shown by passing in the -n flag to svn. Add --stat to see the files affected by the commit:
git log -5
Adding new files
All the files with the translatable strings must be listed in the po/POTFILES.in or po/POTFILES.skip files. This means that most new files must have their names added to these files.
Please remember to do this for new files that you add to Git.
You can make a test on a local copy:
./autogen.sh PYTHONPATH=../../trunk/src python po/test/po_test.py
where ../.. is the path to your local copy
Remember to remove references to the file from the po/POTFILES.in and po/POTFILES.skip files.
Bugfixes in branches
Whenever a bug is fixed in a maintenance branch, it is the committer's responsibility to make sure the fix is also committed to the master branch. See the Brief introduction to Git for details.