[PATCH 2/3] maint: Tweak HACKING for generated ChangeLog

Signed-off-by: Eric Blake <[email protected]>
---
 HACKING | 39 +++++++++++++++++++++------------------
 1 file changed, 21 insertions(+), 18 deletions(-)

diff --git a/HACKING b/HACKING
index 07d7bcd..0f53bb8 100644
--- a/HACKING
+++ b/HACKING
@@ -33,16 +33,6 @@ generate the version string.  Therefore, we recommend:

 - Git 1.4.4+ <http://git.or.cz/>

-You may find it useful to install the git-merge-changelog merge driver:
-http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c
-
-then add the following to .git/config or ~/.gitconfig:
-[merge "merge-changelog"]
-	name = GNU ChangeLog merge driver
-	driver = git-merge-changelog %O %A %B
-[diff "texinfo"]
-	funcname = ^@node[\t ][\t ]*\\([^,][^,]*\\)
-
 Only building the initial full source tree will be a bit painful.
 Later, a plain `git pull && make' should be sufficient.

@@ -128,18 +118,32 @@ you'd use doc/Copyright/request-assign.future:

 * Administrivia

+** The ChangeLog is generated from git commit comments.
+
+Your commit log should always start with a one-line summary, the second
+line should be blank, and the remaining lines are usually ChangeLog-style
+entries for all affected files.  However, it's fine -- even recommended --
+to write a few lines of prose describing the change, when the summary
+and ChangeLog entries don't give enough of the big picture.  Omit the
+leading TABs that you're used to seeing in a "real" ChangeLog file, but
+keep the maximum line length at 72 or smaller, so that the generated
+ChangeLog lines, each with its leading TAB, will not exceed 80 columns.
+As for the ChangeLog-style content, please follow these guidelines:
+
+  http://www.gnu.org/software/guile/changelogs/guile-changelogs_3.html
+
 ** If you incorporate a change from somebody on the net:
 First, if it is a large change, you must make sure they have signed
 the appropriate paperwork.  Second, be sure to add their name and
 email address to THANKS.

 ** Test fixes
-If a change fixes a test, mention the test in the ChangeLog entry.
-To this end, the Autotest-mode is handy.
+If a change fixes a test, mention the test in the commit log. To this
+end, the Autotest-mode is handy.

 ** Bug reports
-If somebody reports a new bug, mention their name in the ChangeLog
-entry and in the test case you write.  Put them into THANKS.
+If somebody reports a new bug, mention their name in the commit log,
+and put them into THANKS.

 The correct response to most actual bugs is to write a new test case
 which demonstrates the bug.  Then fix the bug, re-run the test suite,
@@ -224,10 +228,9 @@ should check the results before committing them in git.

 ** Set the version number
 Update the version number in NEWS (with version, date, and release
-type) and ChangeLog, and mention in README whether the release is
-stable.  Make sure all changes are committed, then run `git tag -s -m
-<version> -u <gpg_key> v<version>'.  Do not push anything upstream at
-this point.
+type), and mention in README whether the release is stable.  Make sure
+all changes are committed, then run `git tag -s -m <version> -u
+<gpg_key> v<version>'.  Do not push anything upstream at this point.

 ** Update configure
 As much as possible, make sure to release an Autoconf that uses
-- 
2.9.3