Difference between revisions of "Committing policies"

From Gramps
Jump to: navigation, search
(Log Messages)
(Log messages)
(18 intermediate revisions by 7 users not shown)
Line 1: Line 1:
==Log Messages==
+
==Log messages==
Every commit to Subversion 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:
+
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 [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.
 
* Messages should attempt to describe how the change affects the functionality from the user's perspective.
* It is not necessary to describe minute details about the change nor the files that are affected because that information is already stored by Subversion.
+
* Use complete sentences when possible.
* If the commit fixes a bug on the [http://bugs.gramps-project.org bug tracker], the log message shall include the bug ID and summary from the tracker.
+
* 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 log message shall list the contributor's name and email.
+
* 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.: [http://sourceforge.net/p/gramps/source/ci/d8acf8e875a06cf89b2cc4d59ed63730539244af/ [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 svn log command, an example usage of this command:
+
You can see the last changes with the git log command, an example usage of this command:
  svn log -r BASE:10240 | head -n 40
+
  git log --oneline
Change 10240 to a more recent version to have the command take less time.
 
  
You can also limit the number of entries shown by passing in the '''--limit''' flag to svn. Add '''-v''' to see the files changed:
+
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:
  
  svn log --limit 5
+
  git log -5
  
==Adding New Files==
+
To credit the contributor of a patch, use:
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.
 
  
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.
+
git commit -m 'Commit message' --author='A U Thor <[email protected]>'
  
You'll also need to set several properties for new files.  For .py files, try the following:
+
==Adding new files==
svn propset svn:mime-type text/plain src/somefile.py
+
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.
svn propset svn:eol-style native src/somefile.py
 
svn propset svn:keywords 'Id' src/somefile.py
 
  
==Bugfixes In Branches==
+
Please remember to do this for new files that you add to Git.
Whenever a bug is fixed in a branch, it is the committer's responsibility to make sure the fix is also committed to the trunk. This can be accomplished using one of three methods. All methods require a working copy of trunk and the branch.
 
  
;Using svn merge
+
===Check===
The most common way to move changes between branches is by using the svn merge command. Assuming you have a working copy of trunk in ~/gramps/trunk and a working copy of the 3.0 branch in ~gramps/gramps30:
 
gramps30$ svn commit
 
gramps30$ cd ../trunk
 
trunk$ svn merge -c REVISION https://gramps.svn.sourceforge.net/svnroot/gramps/branches/gramps30
 
trunk$ svn commit
 
  
;Using svn diff
+
You can make a test on a local copy:
You can also create a patch on gramps30 branch and apply it to trunk:
+
  ./autogen.sh
  gramps30$  svn diff -r PREV > ~/mypatch.patch
+
  PYTHONPATH=../../trunk/src python po/test/po_test.py
  gramps30$  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:
+
where ../.. is the path to your local copy
trunk$  ./svnci
 
  
;Manually
+
==Removing files==
Make the change in the branch. Commit the change to the branch.  
+
Remember to remove references to the file from the po/POTFILES.in and po/POTFILES.skip files.
  
Make the change in trunk. Commit the change to trunk.
+
==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.
  
More info: http://svnbook.red-bean.com/
+
[[Category:Developers/General]]

Revision as of 22:57, 30 December 2013

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

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:

./autogen.sh
PYTHONPATH=../../trunk/src 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.