Changes between Version 13 and Version 14 of TracDev/SubmittingPatches

Timestamp:

Dec 12, 2010, 12:39:20 PM (13 years ago)

Author:

Christian Boos

Comment:

also mention Mercurial and Git as alternatives for doing the checkout

TracDev/SubmittingPatches

@@ -41 +41 @@
 }}}
 
-See [DevelopmentEnvironmentSetup how to setup a development environment].
+If you're familiar with DVCS systems like Git or Mercurial, all the better, you should rather pick one of the official mirrors (see TracRepositories#OfficialMirrors) and develop your patches using these tools. The advantage over Subversion is that you can "document" your patches by directly adding a commit log message to them and the tool will help you maintain your patches while Trac continues to evolve upstream.
+
+Then see [DevelopmentEnvironmentSetup how to setup a development environment].
 
 == Make some changes ==
@@ -63 +65 @@
 }}}
 
+The same applies if you use Mercurial, and in Git you'll also have to "add" modified files to the index.
+
 == Make the patch ==
 
@@ -73 +77 @@
 
 Note that `svn diff` will generate a diff in the unified format. If for some reason you use the `diff` tool to produce the patch, then please use `diff -u` otherwise the diff won't be an unified diff.
+
+With Mercurial or Git, make a commit with a detailed log message (the one you'd like to see later on in Trac itself!) and then export it.
+
+With mercurial, assuming your patch corresponds to the latest commit:
+{{{
+hg export tip > my_patch_file.diff
+}}}
+
+With git, assuming your patch corresponds to the head:
+{{{
+git show  > my_patch_file.diff
+}}}
 
 == Submit the patch ==
@@ -98 +114 @@
  - and of course, the quality of the code, the pertinence of the fix or the feature is the main criterion
 
-See for example #9718.
+See for example #8935, #9718.
 
 That can be hard to get right the first time, so you'll certainly get asked to improve your patch. You should be willing to take feedback into account and maybe do a few iterations of the patch, if needed.