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
