+- Start with a single unindented summary line explaining the change;
+ do not end this line with a period. If that line starts with a
+ semicolon and a space "; ", the commit message will be ignored when
+ generating the ChangeLog file. Use this for minor commits that do
+ not need separate ChangeLog entries, such as changes in etc/NEWS.
+
+- After the summary line, there should be an empty line, then
+ unindented ChangeLog entries.
+
+- Limit lines in commit messages to 78 characters, unless they consist
+ of a single word of at most 140 characters; this is enforced by a
+ commit hook. It's nicer to limit the summary line to 50 characters;
+ this isn't enforced. If the change can't be summarized so briefly,
+ add a paragraph after the empty line and before the individual file
+ descriptions.
+
+- If only a single file is changed, the summary line can be the normal
+ file first line (starting with the asterisk). Then there is no
+ individual files section.
+
+- If the commit has more than one author, the commit message should
+ contain separate lines to mention the other authors, like the
+ following:
+
+ Co-authored-by: Joe Schmoe <j.schmoe@example.org>
+
+- If the commit is a tiny change that is exempt from copyright paperwork,
+ the commit message should contain a separate line like the following:
+
+ Copyright-paperwork-exempt: yes
+
+- The commit message should contain "Bug#NNNNN" if it is related to
+ bug number NNNNN in the debbugs database. This string is often
+ parenthesized, as in "(Bug#19003)".
+
+- Commit messages should contain only printable UTF-8 characters.
+
+- Commit messages should not contain the "Signed-off-by:" lines that
+ are used in some other projects.
+
+- Any lines of the commit message that start with "; " are omitted
+ from the generated ChangeLog.
+
+- Explaining the rationale for a design choice is best done in comments
+ in the source code. However, sometimes it is useful to describe just
+ the rationale for a change; that can be done in the commit message
+ between the summary line and the file entries.
+
+- Emacs generally follows the GNU coding standards for ChangeLogs: see
+ http://www.gnu.org/prep/standards/html_node/Change-Logs.html
+ or run 'info "(standards)Change Logs"'. One exception is that
+ commits still sometimes quote `like-this' (as the standards used to
+ recommend) rather than 'like-this' or ‘like this’ (as they do now),
+ as `...' is so widely used elsewhere in Emacs.
+
+- Some commenting rules in the GNU coding standards also apply
+ to ChangeLog entries: they must be in English, and be complete
+ sentences starting with a capital and ending with a period (except
+ the summary line should not end in a period). See
+ http://www.gnu.org/prep/standards/html_node/Comments.html
+ or run 'info "(standards)Comments"'.
+
+ They are preserved indefinitely, and have a reasonable chance of
+ being read in the future, so it's better that they have good
+ presentation.
+
+- Use the present tense; describe "what the change does", not "what
+ the change did".
+
+- Preferred form for several entries with the same content:
+
+ * lisp/help.el (view-lossage):
+ * lisp/kmacro.el (kmacro-edit-lossage):
+ * lisp/edmacro.el (edit-kbd-macro): Fix docstring, lossage is now 300.
+
+ (Rather than anything involving "ditto" and suchlike.)
+
+- There is no standard or recommended way to identify revisions in
+ ChangeLog entries. Using Git SHA1 values limits the usability of
+ the references to Git, and will become much less useful if Emacs
+ switches to a different VCS. So we recommend against that.
+
+ One way to identify revisions is by quoting their summary line.
+ Another is with an action stamp - an RFC3339 date followed by !
+ followed by the committer's email - for example,
+ "2014-01-16T05:43:35Z!esr@thyrsus.com". Often, "my previous commit"
+ will suffice.
+
+- There is no need to mention files such as NEWS and MAINTAINERS, or
+ to indicate regeneration of files such as 'lib/gnulib.mk', in the
+ ChangeLog entry. "There is no need" means you don't have to, but
+ you can if you want to.
+
+** Generating ChangeLog entries
+
+- You can use Emacs functions to write ChangeLog entries; see
+ http://www.gnu.org/software/emacs/manual/html_node/emacs/Change-Log-Commands.html
+ or run 'info "(emacs)Change Log Commands"'.
+
+- If you use Emacs VC, one way to format ChangeLog entries is to create
+ a top-level ChangeLog file manually, and update it with 'C-x 4 a' as
+ usual. Do not register the ChangeLog file under git; instead, use
+ 'C-c C-a' to insert its contents into into your *vc-log* buffer.
+ Or if 'log-edit-hook' includes 'log-edit-insert-changelog' (which it
+ does by default), they will be filled in for you automatically.
+
+- Alternatively, you can use the vc-dwim command to maintain commit
+ messages. When you create a source directory, run the shell command
+ 'git-changelog-symlink-init' to create a symbolic link from
+ ChangeLog to .git/c/ChangeLog. Edit this ChangeLog via its symlink
+ with Emacs commands like 'C-x 4 a', and commit the change using the
+ shell command 'vc-dwim --commit'. Type 'vc-dwim --help' for more.
+
+** Branches
+
+Future development normally takes place on the master branch.
+Sometimes specialized features are developed on other branches before
+possibly being merged to the master. Release branches are named
+"emacs-NN" where NN is the major version number, and are mainly
+intended for more-conservative changes such as bug fixes. Typically,
+collective development is active on the master branch and possibly on
+the current release branch. Periodically, the current release branch
+is merged into the master, using the gitmerge function described in
+admin/notes/git-workflow.
+
+If you are fixing a bug that exists in the current release, be sure to
+commit it to the release branch; it will be merged to the master
+branch later by the gitmerge function.
+
+However, if you know that the change will be difficult to merge to the
+master (e.g., because the code on master has changed a lot), you can
+apply the change to both master and branch yourself. It could also
+happen that a change is cherry-picked from master to the release
+branch, and so doesn't need to be merged back. In these cases,
+say in the release branch commit message that there is no need to merge
+the commit to master, by starting the commit message with "Backport:".
+The gitmerge function excludes these commits from the merge to the master.
+
+Some changes should not be merged to master at all, for whatever
+reasons. These should be marked by including something like "Do not
+merge to master" or anything that matches gitmerge-skip-regexp (see
+admin/gitmerge.el) in the commit message.
+
+** Other process information