Generate a ChangeLog file from commit logs

* .gitignore: Add 'ChangeLog'.
* build-aux/gitlog-to-changelog: New file, from Gnulib.
* build-aux/gitlog-to-emacslog: New file.
* CONTRIBUTE: Document the revised workflow.
* Makefile.in (clean): Remove *.tmp and etc/*.tmp*
instead of just special cases.
(CHANGELOG_HISTORY_INDEX_MAX, CHANGELOG_N, gen_origin): New vars.
(ChangeLog, unchanged-history-files, change-history)
(change-history-commit): New rules.
* admin/admin.el (make-manuals-dist--1):
Don't worry about doc/ChangeLog.
* admin/authors.el: Add a FIXME.
* admin/make-tarball.txt:
* lisp/calendar/icalendar.el:
* lisp/gnus/deuglify.el:
* lisp/obsolete/gulp.el:
* lwlib/README:
Adjust to renamed ChangeLog history files.
* admin/merge-gnulib (GNULIB_MODULES): Add gitlog-to-changelog.
* admin/notes/repo: Call it 'master' a la Git, not 'trunk' a la Bzr.
Remove obsolete discussion of merging ChangeLog files.
New section "Maintaining ChangeLog history".
* build-aux/git-hooks/pre-commit:
Reject attempts to commit files named 'ChangeLog'.
* lib/gnulib.mk, m4/gnulib-comp.m4: Regenerate.
* make-dist: Make and distribute top-level ChangeLog if there's a
.git directory.  Distribute the new ChangeLog history files
instead of scattered ChangeLog files.  Distribute the new files
gitlog-to-changelog and gitlog-to-emacslog.
Fixes: bug#19113

5 files changed, 52 insertions, 39 deletions

diff --git a/admin/admin.el b/admin/admin.el
index 9bf503ef142..f7b915509fb 100644
--- a/admin/admin.el
+++ b/admin/admin.el
@@ -28,10 +28,6 @@
 
 (defvar add-log-time-format)            ; in add-log
 
-;; Does this information need to be in every ChangeLog, as opposed to
-;; just the top-level one?  Only if you allow changes the same
-;; day as the release.
-;; http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00161.html
 (defun add-release-logs (root version &optional date)
   "Add \"Version VERSION released.\" change log entries in ROOT.
 Root must be the root of an Emacs source tree.
@@ -601,7 +597,7 @@ style=\"text-align:left\">")
     (copy-file "../doc/misc/texinfo.tex" stem)
     (or (equal type "emacs") (copy-file "../doc/emacs/emacsver.texi" stem))
     (dolist (file (directory-files (format "../doc/%s" type) t))
-      (if (or (string-match-p "\\(\\.texi\\'\\|/ChangeLog\\|/README\\'\\)" file)
+      (if (or (string-match-p "\\(\\.texi\\'\\|/README\\'\\)" file)
               (and (equal type "lispintro")
                    (string-match-p "\\.\\(eps\\|pdf\\)\\'" file)))
           (copy-file file stem)))
diff --git a/admin/authors.el b/admin/authors.el
index 1e4af9bbace..1f7e542478b 100644
--- a/admin/authors.el
+++ b/admin/authors.el
@@ -27,6 +27,9 @@
 ;; Use M-x authors RET to create an *Authors* buffer that can used as
 ;; or merged with Emacs's AUTHORS file.
 
+;; FIXME: This needs to modernized in the light of current practice,
+;; which generates a single top-level ChangeLog file from commit logs.
+
 ;;; Code:
 
 (defvar authors-coding-system 'utf-8
@@ -76,7 +79,7 @@ files.")
     ("Gerd Möllmann" "Gerd Moellmann")
     ("Hallvard B. Furuseth" "Hallvard B Furuseth" "Hallvard Furuseth")
     ("Hrvoje Nikšić" "Hrvoje Niksic")
-    ;; lisp/org/ChangeLog 2010-11-11.
+    ;; lisp/org/ChangeLog.1 2010-11-11.
     (nil "aaa bbb")
     (nil "Code Extracted") ; lisp/newcomment.el's "Author:" header
     ("Jaeyoun Chung" "Jae-youn Chung" "Jae-you Chung" "Chung Jae-youn")
diff --git a/admin/make-tarball.txt b/admin/make-tarball.txt
index e902b023f80..8190e9edb85 100644
--- a/admin/make-tarball.txt
+++ b/admin/make-tarball.txt
@@ -31,28 +31,33 @@ General steps (for each step, check for possible errors):
       M-x authors RET
 
     If there is an "*Authors Errors*" buffer, address the issues.
-    If there was a ChangeLog typo, fix it.  If a file was deleted or
-    renamed, consider adding an appropriate entry to authors-ignored-files,
-    authors-valid-file-names, or authors-renamed-files-alist.
+    If there was a ChangeLog typo, run "make change-history" and then
+    fix the newest ChangeLog history file.  If a file was deleted or
+    renamed, consider adding an appropriate entry to
+    authors-ignored-files, authors-valid-file-names, or
+    authors-renamed-files-alist.
 
     If necessary, repeat M-x authors after making those changes.
     Save the "*Authors*" buffer as etc/AUTHORS.
     Check the diff looks reasonable.  Maybe add entries to
     authors-ambiguous-files or authors-aliases, and repeat.
-    Commit any fixes to ChangeLogs or authors.el.
+    Commit any fixes to authors.el.
 
 3.  Set the version number (M-x load-file RET admin/admin.el RET, then
     M-x set-version RET).  For a release, add released ChangeLog
-    entries (M-x add-release-logs RET).
+    entries (create a ChangeLog symlink a la vc-dwim, then run M-x
+    add-release-logs RET, then run the shell command 'vc-dwim --commit').
 
     For a pretest, start at version .90.  After .99, use .990 (so that
     it sorts).
 
     The final pretest should be a release candidate.  Set the version
     number to that of the actual release.  Pick a date about a week
-    from now when you intend to make the release.  Use M-x add-release-logs
-    to add the ChangeLog entries for that date to the tar file (but
-    do not commit the entries to the repository until the actual release).
+    from now when you intend to make the release.  Use vc-dwim and
+    M-x add-release-logs as described above to add commit messages
+    that will appear in the tarball's automatically-generated ChangeLog
+    file as entries for that date.
+
     Name the tar file as emacs-XX.Y-rc1.tar.  If all goes well in the
     following week, you can simply rename the file and use it for the
     actual release.  If you need another release candidate, remember
@@ -67,8 +72,7 @@ General steps (for each step, check for possible errors):
 5.  Copy lisp/loaddefs.el to lisp/ldefs-boot.el.
 
     Commit etc/AUTHORS, lisp/ldefs-boot.el, and the files changed
-    by M-x set-version. For a release, also commit the ChangeLog
-    files in all directories.
+    by M-x set-version.
 
     If someone else made a commit between step 1 and now,
     you need to repeat from step 4 onwards.  (You can commit the files
diff --git a/admin/merge-gnulib b/admin/merge-gnulib
index 9e2b10dc4ce..e63422b0d5e 100755
--- a/admin/merge-gnulib
+++ b/admin/merge-gnulib
@@ -31,7 +31,7 @@ GNULIB_MODULES='
   crypto/md5 crypto/sha1 crypto/sha256 crypto/sha512
   dtoastr dtotimespec dup2 environ execinfo faccessat
   fcntl fcntl-h fdatasync fdopendir filemode fstatat fsync
-  getloadavg getopt-gnu gettime gettimeofday
+  getloadavg getopt-gnu gettime gettimeofday gitlog-to-changelog
   intprops largefile lstat
   manywarnings memrchr mkostemp mktime
   pipe2 pselect pthread_sigmask putenv qacl readlink readlinkat
diff --git a/admin/notes/repo b/admin/notes/repo
index 4f9dc59eb0f..f38fd2cc3a8 100644
--- a/admin/notes/repo
+++ b/admin/notes/repo
@@ -10,10 +10,10 @@ instructions.
 * Install changes only on one branch, let them get merged elsewhere if needed.
 
 In particular, install bug-fixes only on the release branch (if there
-is one) and let them get synced to the trunk; do not install them by
-hand on the trunk as well.  E.g. if there is an active "emacs-24" branch
+is one) and let them get synced to the master; do not install them by
+hand on the master as well.  E.g. if there is an active "emacs-24" branch
 and you have a bug-fix appropriate for the next emacs-24.x release,
-install it only on the emacs-24 branch, not on the trunk as well.
+install it only on the emacs-24 branch, not on the master as well.
 
 Installing things manually into more than one branch makes merges more
 difficult.
@@ -21,10 +21,10 @@ difficult.
 http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01124.html
 
 The exception is, if you know that the change will be difficult to
-merge to the trunk (eg because the trunk code has changed a lot).
-In that case, it's helpful if you can apply the change to both trunk
+merge to the master (eg because the master code has changed a lot).
+In that case, it's helpful if you can apply the change to both master
 and branch yourself (when committing the branch change, indicate
-in the commit log that it should not be merged to the trunk, by
+in the commit log that it should not be merged to the master, by
 including the phrase "Not to be merged to master", or any other phrase
 that matches "merge").
 
@@ -32,14 +32,14 @@ that matches "merge").
 
 If your branch has only a single commit, or many different real
 commits, it is fine to do a merge.  If your branch has only a very
-small number of "real" commits, but several "merge from trunks", it is
-preferred that you take your branch's diff, apply it to the trunk, and
+small number of "real" commits, but several "merge from masters", it is
+preferred that you take your branch's diff, apply it to the master, and
 commit directly, not merge.  This keeps the history cleaner.
 
 In general, when working on some feature in a separate branch, it is
-preferable not to merge from trunk until you are done with the
+preferable not to merge from master until you are done with the
 feature.  Unless you really need some change that was done on the
-trunk while you were developing on the branch, you don't really need
+master while you were developing on the branch, you don't really need
 those merges; just merge once, when you are done with the feature, and
 Bazaar will take care of the rest.  Bazaar is much better in this than
 CVS, so interim merges are unnecessary.
@@ -66,22 +66,14 @@ variable in admin/merge-gnulib before running it.
 If you remove a gnulib module, or if a gnulib module
 removes a file, then remove the corresponding files by hand.
 
-* How to merge changes from emacs-24 to trunk
+* How to merge changes from emacs-24 to master
 
-[The section on git merge procedure has not yet been written]
-
-Inspect the change log entries (e.g. in case too many entries have been
-included or whitespace between entries needs fixing). If someone made
-multiple change log entries on different days in the branch, you may
-wish to collapse them all to a single entry for that author in the
-trunk (because in the trunk they all appear under the same date).
-Obviously, if there are multiple changes to the same file by different
-authors, don't break the logical ordering in doing this.
+[The section on git merge procedure has not yet been written.]
 
 You may see conflicts in autoload md5sums in comments.  Strictly
 speaking, the right thing to do is merge everything else, resolve the
-conflict by choosing either the trunk or branch version, then run
-`make -C lisp autoloads' to update the md5sums to the correct trunk
+conflict by choosing either the master or branch version, then run
+`make -C lisp autoloads' to update the md5sums to the correct master
 value before committing.
 
 * Re-adding a file that has been removed from the repository
@@ -124,3 +116,21 @@ again.
 
 This is a semi-automated way to find the revision that introduced a bug.
 Browse `git help bisect' for technical instructions.
+
+* Maintaining ChangeLog history
+
+Older ChangeLog entries are kept in history files named ChangeLog.1,
+ChangeLog.2, etc., and can be edited just as any other source files
+can.  Newer ChangeLog entries are stored in the repository as commit
+messages, which cannot be edited directly.
+
+'make ChangeLog' copies newer ChangeLog entries into a file
+'ChangeLog' that is intended to be put into the distribution tarball.
+This ChangeLog file is not put into the repository.
+
+'make change-history' copies all newer ChangeLog entries into the
+start of the newest ChangeLog history file.  These ChangeLog entries
+are thereafter considered to be old, so later uses of 'make ChangeLog'
+and/or 'make change-history' will no longer copy the entries.  To
+alter ChangeLog history, run 'make change-history', then edit
+the ChangeLog history files manually and commit your changes.