[gimp-web] Update bugs/howtos/submit-patch.htrw to git

[Martin Nordholts <martinn src gnome org>]

commit cbeed47a7932837db5e7c05e86865e072f5debd8
Author: Martin Nordholts <martinn src gnome org>
Date:   Wed Jul 15 10:18:42 2009 +0200

    Update bugs/howtos/submit-patch.htrw to git

 bugs/howtos/submit-patch.htrw |   63 ++++++++++++++++++++---------------------
 1 files changed, 31 insertions(+), 32 deletions(-)
---
diff --git a/bugs/howtos/submit-patch.htrw b/bugs/howtos/submit-patch.htrw
index add8918..7e751a7 100644
--- a/bugs/howtos/submit-patch.htrw
+++ b/bugs/howtos/submit-patch.htrw
@@ -11,42 +11,41 @@
   It is normally a plain text file containing only the differences between the current version of the
   code and the fixed version.
 </p>
-<p>
-  Many people have been submitting patches to the mailing lists and this is a small problem,
-  the patch might be big and sending the patch via mail is not a very good idea.
-  This howto here to remind you not to send the patch via the mailing list but using the tools outside
-  of the mailing lists.
-</p>
-<p>
-  I hope that people will start to give mailing lists a bit more respect and maybe will stop sending
-  patches to the list after reading this.
-</p>
 
 <h1>Generating a Patch</h1>
-<h2>Against Current CVS</h2>
+<h2>With git</h2>
 <p>
-  The preferred way of creating a patch is to create it against current CVS. The ensures that the patch works
-  with the latest edition of the source code and makes it easier for the developers to apply the patch.
+  The preferred way of creating a patch is to create it against
+  current git. The ensures that the patches works with the latest
+  edition of the source code and makes it easier for the developers to
+  apply the patch.
 </p>
 <p>
-  To generate the patch you need to check out a copy of the source code from CVS. More information on how
-  to do this can be found in the <a href="wgo:source-howtos-stable_cvs_get">CVS HOWTO</a>. After you have made the
-  changes to the source code and made sure it compiles and works as expected, you can create the patch file using
-  the command <kbd>cvs diff -up &gt; /path/to/patchfile.patch</kbd>. It is recommended to include the <kbd>diff -up</kbd>
-  line in ~/.cvsrc. To summarize the steps:
+  Clone the git repository which is
+  <pre>
+git clone git://git.gnome.org/gimp
+</pre>
+  Create commits that fixes the problem. For small problems it will
+  only be a single commit. Be sure to provide your name and email in
+  the commits. Refer to git guides on the net on how to work with git.
+</p>
+<p>
+  Now that you have commits that fixes the problem, create patches by doing
+  <pre>
+git format-patch origin/master
+</pre>
+  This will give you patch files in the form of git commits with names like
+  <pre>
+0001-plug-ins-Use-string-literal-as-format-in-metadata-p.patch
+</pre>
+  We prefer to have the patches attached to bug reports in Bugzilla (see
+  below) but it is also fine to send them to the mailing list if they
+  are reasonably small.
 </p>
-<ul>
-  <li>Check out a copy of the source code from CVS</li>
-  <li>Apply your changes to the source</li>
-  <li>Re-compile and make sure it works as expected</li>
-  <li>Generate the patch file using <kbd>cvs diff -up &gt; /path/to/patchfile.patch</kbd></li>
-  <li>Examine the resulting .patch file to make sure it contains only the intended changes</li>
-  <li>Submit the patch using Bugzilla, see below</li>
-</ul>
 
 <h2>Against the Latest Release</h2>
 <p>
-  If you do not have access to CVS you can generate the patch against the latest release.
+  If you do not have access to git you can generate the patch against the latest release.
 </p>
 <p>
   To generate the patch you will need two copies of the source code: one that is unmodified and one containing
@@ -81,7 +80,7 @@
 </ul>
 <p>
   If you have a patch that is closing bugs then you can attach the patch to the bug/bugs explaining
-  what the patch is doing. You can also inform the gimp-devel mailing list about the closed bug but don't
+  what the patch is doing. You can also inform the gimp-developer mailing list about the closed bug but avoid to
   attach the patch to the mail sent to the list, instead put the bug links in the mail where the attached
   patch is located.
 </p>
@@ -90,13 +89,13 @@
   <li>Find the bug it is closing in the <a href="http://bugzilla.gnome.org/buglist.cgi?product=GIMP&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED";>Open bugs</a> list.</li>
   <li>Attach the patch to the bug report.</li>
   <li>Explain what the patch is doing and if there might be any problems with the patch.</li>
-  <li>If you want to send a mail to the gimp-devel list and explain it there also. 
+  <li>If you want to send a mail to the gimp-developer list and explain it there also. 
   Remember to have the bug number or even better the link to the bug in the mail. 
-  Don't attach the patch to the mail.</li>
+  Avoid attaching the patch to the mail.</li>
 </ol>
 <p>
   Now you just have to wait for the developers and maintainers to look at the patch and see if this
-  is really closing the bug and if it might open new bugs. With a bit of luck it will be implemented
+  is really closing the bug and if it might open new bugs. If everything is fine it will be implemented
   in a release done soon either stable or development version.
 </p>
 
@@ -121,7 +120,7 @@
 <h2>Remember to</h2>
 <ul>
   <li>use the same coding style, see file HACKING</li>
-  <li>never send the patch as a attachment to the mailing lists.</li>
+  <li>avoid sending the patch as an attachment to the mailing lists.</li>
   <li>explain what the patch is doing to GIMP.</li>
   <li>report the bugs that the patch is closing.</li>
   <li>always test the patch before submitting it.</li>