Github/emacs
2
0
Fork 1
mirror of git://git.sv.gnu.org/emacs.git synced 2026-02-16 09:14:18 +00:00
Code Issues Projects Releases Packages Wiki Activity

Minor fixes in the changes in preparation for git migration.

Browse source 
src/Makefile.in (repo-update): Fix a typo and slightly reword
 commentary.

 admin/notes/repo (Notes): Reword the stylistic guidance for commit log
 messages so that they are in line with Emacs development practices
 and style guidance.
This commit is contained in:
Eli Zaretskii 2014-10-31 11:32:11 +02:00
parent 15d0d8d11b
commit b8ff3a9f98
4 changed files with 25 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
admin/ChangeLog
View file

@ -1,3 +1,9 @@
2014-10-31 Eli Zaretskii <eliz@gnu.org>
* notes/repo (Notes): Reword the stylistic guidance for commit log
messages so that they are in line with Emacs development practices
and style guidance.
2014-10-31 Eric S. Raymond <esr@thyrsus.com>
* notes/bzr: Renamed to notes/repo, reorganixed to separate

19
admin/notes/repo
View file

@ -5,18 +5,15 @@ NOTES ON COMMITTING TO EMACS'S REPOSITORY -*- outline -*-
Commits should follow the conventions used in all modern distributed
version-control systems. That is, they should consist of
- A self-contained topic line no more than 75 chars long.
- A self-contained topic line, preferably no more than 75 chars long.
- If other content follows the topic line, there should be
a blank line separating the two.
- If other content follows the topic line, there should be a blank
line separating the two.
Try to keep your commits - and your commit comments - small. If
you feel an urge to put a bullet list in your commit comment, it's
doing too many things at once.
Yes, these directins are a departure from historical Emacs practice,
but it helps modern log-viewing and summary tools work better so that
other people can comprehend your code.
- Follow the blank line with ChangeLog-like entries for the specific
changes you made, if any. (As long as Emacs maintains ChangeLog
files, just copy the entries you made in them to the commit message
after the blank line.)
* Commit to the right branch
@ -184,7 +181,7 @@ the trunk at all, use `bzr resolve path/to/file --take-this' to keep the
trunk version. Prior to bzr 2.2.3, this may fail. You can just
delete the .OTHER etc files by hand and use bzr resolve path/to/file.
* Sanity-checking branch merges
* Sanity-checking branch merges
Inspect the ChangeLog entries (e.g. in case too many entries have been
included or whitespace between entries needs fixing). bzrmerge tries

5
lisp/ChangeLog
View file

@ -1,3 +1,8 @@
2014-10-31 Eli Zaretskii <eliz@gnu.org>
* Makefile.in (repo-update): Fix a typo and slightly reword
commentary.
2014-10-31 Glenn Morris <rgm@gnu.org>
* version.el (emacs-bzr-version, emacs-bzr-get-version):

12
lisp/Makefile.in
View file

@ -211,12 +211,12 @@ update-subdirs: doit
# Some modes of make-dist use this.
updates: update-subdirs autoloads finder-data custom-deps
# This is useful after a repostiory fetch; but it doesn't do anything that a
# plain "make" at top-level doesn't.
# The only difference between this and this directory's "all" rule
# is that this runs "autoloads" as well (because it uses "compile"
# rather than "compile-main"). In a bootstrap, $(lisp) in src/Makefile
# triggers this directory's autoloads rule.
# This is useful after updating from the repository; but it doesn't do
# anything that a plain "make" at top-level doesn't. The only
# difference between this and this directory's "all" rule is that this
# runs "autoloads" as well (because it uses "compile" rather than
# "compile-main"). In a bootstrap, $(lisp) in src/Makefile triggers
# this directory's autoloads rule.
repo-update: compile finder-data custom-deps
# Update the AUTHORS file.