+* When merging, prefer 'git merge --log' over plain 'git merge', so that
+ a later 'git log' gives an indication of which actual patches were
+ merged even when they don't appear early in the list.
+
+* The 'master', 'maint' and 'micro' branches should not be rewound, i.e.,
+ should always fast-forward, except maybe for privacy issues. For
+ feature branches, the announcement for the branch should document
+ the rewinding policy.
+ If a topic branch is expected to be rewound, it is good practice to put
+ it in the 'experimental/*' namespace; for example, a rewindable branch
+ dealing with Vala support could be named like "experimental/vala-work".
+
+============================================================================
+= Writing a good commit message
+
+* Here is the general format that Automake's commit messages are expected
+ to follow. See the further points below for clarifications and minor
+ corrections.
+
+ topic: brief description (this is the "summary line")
+
+ <reference to relevant bugs, if any>
+
+ Here goes a more detailed explanation of why the commit is needed,
+ and a general overview of what it does, and how. This section
+ should almost always be provided, possibly only with the expection
+ of obvious fixes or very trivial changes.
+
+ And if the detailed explanation is quite long or detailed, you can
+ want to break it in more paragraphs.
+
+ Then you can add references to relevant mailing list discussions
+ (if any), with proper links. But don't take this as an excuse for
+ writing incomplete commit messages! The "distilled" conclusions
+ reached in such discussions should have been placed in the
+ paragraphs above.
+
+ Finally, here you can thank people that motivated or helped the
+ change. So, thanks to John Doe for bringing up the issue, and to
+ J. Random Hacker for providing suggestions and testing the patch.
+
+ <detailed list of touched files>
+
+* The <detailed list of touched files> should usually be provided (but
+ for short or trivial changes), and should follow the GNU guidelines
+ for ChangeLog entries (described explicitly in the GNU Coding
+ Standards); it might be something of this sort:
+
+ * some/file (func1): Improved frobnication.
+ (func2): Adjusted accordingly.
+ * another/file (foo, bar): Likewise.
+ * tests/foo.tap: New test.
+ * tests/Makefile.am (TESTS): Add it.
+
+* If your commit fixes an automake bug registered in the tracker (say
+ numbered 1234), you should put the following line after the summary
+ line:
+
+ This change fixes automake bug#1234.
+
+* If your commit is just related to the given bug report, but does not
+ fix it, you might want to add a line like this instead:
+
+ This change is related to automake bug#1234.