(no commit message)
authorhttps://www.google.com/accounts/o8/id?id=AItOawmCVaCpC6As7EZbwfzjUyvJozhjpjtfMUs <Jeff@web>
Thu, 26 May 2011 19:12:31 +0000 (12:12 -0700)
committerOpenAFS Wiki <ikiwiki@openafs.org>
Thu, 26 May 2011 19:12:31 +0000 (12:12 -0700)
AFSLore/GitDevelopers.mdwn

index 56fbc88..595703d 100644 (file)
@@ -194,7 +194,7 @@ The hook can be downloaded from the [[OpenAFS]] gerrit server by running the fol
 
 When submitting to gerrit, it's important to realise that each commit in your branch will become a changeset in the upstream OpenAFS, typically with no modification at our end. It is therefore important that these commits follow some simple rules...
 
-First, each commit should be complete. The maxim "one change per commit, one commit per change" applies here. Each commit should build and test in its own right. Typically, this means that a change will be in a small number of commits. If, during development, you have created many more than this (for example, you've created a large number of bug fix commits), please use 'git rebase', or cherry pick these commits into a separate tree before uploading them.
+First, each commit should be complete. The maxim "one change per commit, one commit per change" applies here. Each commit should build and test in its own right. Typically, this means that a change will be in a small number of commits. If, during development, you have created many more than this (for example, you've created a large number of bug fix commits), please use 'git rebase', or cherry pick these commits into a separate tree before uploading them.  Note, however, that "one change" could equate to a change to source code and a change to the corresponding documentation for that code specific change.
 
 Secondly, each commit should have a meaningful revision log. The internals of git means that we can't easily edit these before pushing them into the tree, so we'd like you to get them right for us! A commit message should be comprised of a single 'subject' line (which must **not** end with a full stop), followed by a blank line, followed by one or more paragraphs explaining the purpose of the patch. If it is intended to fix a bug in OpenAFS RT, then the word 'FIXES' followed by the bug number or comma-separated list of bug numbers should be included on a line of its own. The 'LICENSE' keyword can be used to indicate code which is covered under a license other than the IPL, although please speak to a gatekeeper if you intend using this. An example commit message would be