Difference between revisions of "Committing policies"

From Gramps
Jump to: navigation, search
(Content moved out of "Brief Introduction to SVN")
 
(Log messages)
(31 intermediate revisions by 10 users not shown)
Line 1: Line 1:
;Adding new files:All the files with the translatable strings '''must''' be listed in the po/POTFILES.in file. This means that most new files must have their names added to that file.
+
==Log messages==
 +
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:
  
:All the files that need to be released '''must''' be listed in the Makefile.am in the same directory. Please remember to do this for new files that you add to SVN.
+
* The first line of the commit message should consist of a short summary of the change.  Maximum 70 characters.
 +
* If the commit fixes a bug on the [http://bugs.gramps-project.org 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 full commit hash. It will automatically be converted into a hyperlink by the GitHub web interface. Note: a 6 hexa digit hash enclosed in brackets WILL NOT WORK with GitHub auto-hyperlinking :-(
  
:You'll also need to set several properties for new files.  For .py files, try the following:
+
You can see the last changes with the git log command, an example usage of this command:
  svn propset svn:mime-type text/plain src/somefile.py
+
  git log --oneline
svn propset svn:eol-style native src/somefile.py
 
svn propset svn:keywords 'Id' src/somefile.py
 
  
;Bugfixes in branches:Whenever a bug is fixed in a branch, it should be the committer's responsibility to make sure the fix is also committed to the trunk.
+
You can also limit the number of entries shown by passing in the '''-n''' flag to git. Add '''--stat''' to see the files affected by the commit:
  
:You can do this manually, but you can also create a patch on gramps22 branch and apply it to trunk:
+
  git log -5
  gramps22$  svn diff -r PREV > ~/mypatch.patch
 
gramps22$  cd ../trunk
 
trunk$  patch -p0 < ~/mypatch.patch
 
  
:Then you may have to fix things that could not be applied due to conflicts. The patch program would mark the conflicts with the <<<<<<, ======, and >>>>>> signs. You will then need to commit your changes:
+
To credit the contributor of a patch, use:
trunk$  ./svnci
 
  
:More info: http://svnbook.red-bean.com/
+
git commit -m 'Commit message' --author='A U Thor <author@example.com>'
  
;ChangeLog entries:Every change to the code should be documented in the top-level ChangeLog file (or in per-directory ChangeLog for po and help directories). When possible, we'd like to stick to the [http://www.gnu.org/prep/standards/html_node/Change-Logs.html GNU ChangeLog standards].
+
==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.
  
:This especially goes for committing contributed code. In that case, the ChangeLog should list the contributor's name and email, not the maintainer's.
+
Please remember to do this for new files that you add to Git.
 +
 
 +
===Check===
 +
 
 +
You can make a test on a local copy:
 +
PYTHONPATH=../../gramps python po/test/po_test.py
 +
 
 +
where ../.. is the path to your local copy
 +
 
 +
==Removing files==
 +
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#Applying a fix to another branch|Brief introduction to Git]] for details.
 +
 
 +
[[Category:Developers/General]]

Revision as of 23:16, 29 December 2015

Log messages

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. Maximum 70 characters.
  • 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 full commit hash. It will automatically be converted into a hyperlink by the GitHub web interface. Note: a 6 hexa digit hash enclosed in brackets WILL NOT WORK with GitHub auto-hyperlinking :-(

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 git. Add --stat to see the files affected by the commit:

git log -5

To credit the contributor of a patch, use:

git commit -m 'Commit message' --author='A U Thor <[email protected]>'

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.

Check

You can make a test on a local copy:

PYTHONPATH=../../gramps python po/test/po_test.py

where ../.. is the path to your local copy

Removing files

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.