admin/notes/repo

   1 NOTES ON COMMITTING TO EMACS'S REPOSITORY    -*- outline -*-
   2
   3 * Commit metainformation
   4
   5 ** Commit in the author's name
   6
   7 If installing changes written by someone else, commit them in their
   8 name, not yours.
   9
  10 ** Commit message format
  11
  12 Commit messages should follow the conventions used in all modern
  13 distributed version-control systems. That is, they should consist of
  14
  15 - A self-contained topic line, preferably no more than 75 chars long.
  16
  17 - If other content follows the topic line, there should be a blank
  18   line separating the two.
  19
  20 - Follow the blank line with ChangeLog-like entries for the specific
  21   changes you made, if any.  (As long as Emacs maintains ChangeLog
  22   files, just copy the entries you made in them to the commit message
  23   after the blank line.)
  24
  25 - Preferred form for several entries with the same content:
  26
  27    * help.el (view-lossage):
  28    * kmacro.el (kmacro-edit-lossage):
  29    * edmacro.el (edit-kbd-macro): Fix docstring, lossage is now 300 keys.
  30
  31   (Rather than anything involving "ditto" and suchlike.)
  32
  33 - Emacs generally follows the GNU coding standards when it comes to ChangeLogs:
  34   http://www.gnu.org/prep/standards/html_node/Change-Logs.html
  35   One exception is that we still sometimes quote `like-this' (as the
  36   standards used to recommend) rather than 'like-this' (as they do now),
  37   because `...' is so widely used elsewhere in Emacs.
  38   http://lists.gnu.org/archive/html/emacs-devel/2014-05/msg00514.html
  39
  40 ** Unnecessary metainformation
  41
  42 There is no need to make separate change log entries for files such as
  43 NEWS, MAINTAINERS, and FOR-RELEASE, or to indicate regeneration of
  44 files such as 'configure'.  "There is no need" means you don't have
  45 to, but you can if you want to.
  46
  47 * Commit to the right branch
  48
  49 Development normally takes places on the trunk.
  50 Sometimes specialized features are developed on separate branches
  51 before possibly being merged to the trunk.
  52
  53 Development is discussed on the emacs-devel mailing list.
  54
  55 Sometime before the release of a new major version of Emacs
  56 a "feature freeze" is imposed on the trunk.  No new features may be
  57 added after this point.  This is usually some months before the release.
  58
  59 Shortly before the release, a release branch is created, and the
  60 trunk is then free for development.
  61
  62 For example, "emacs-23" for Emacs 23.2 and later, "EMACS_23_1_RC" for
  63 23.1, "EMACS_22_BASE" for 22.x, and "EMACS_21_1_RC" for 21.x.
  64
  65 Consult emacs-devel for exactly what kinds of changes are allowed
  66 on what branch at any time.
  67
  68 ** elpa
  69
  70 This branch does not contain a copy of Emacs, but of the Emacs Lisp
  71 package archive (elpa.gnu.org).  See admin/notes/elpa for further
  72 explanation, and the README file in the branch for usage
  73 instructions.
  74
  75 * Install changes only on one branch, let them get merged elsewhere if needed.
  76
  77 In particular, install bug-fixes only on the release branch (if there
  78 is one) and let them get synced to the trunk; do not install them by
  79 hand on the trunk as well.  E.g. if there is an active "emacs-24" branch
  80 and you have a bug-fix appropriate for the next emacs-24.x release,
  81 install it only on the emacs-24 branch, not on the trunk as well.
  82
  83 Installing things manually into more than one branch makes merges more
  84 difficult.
  85
  86 http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01124.html
  87
  88 The exception is, if you know that the change will be difficult to
  89 merge to the trunk (eg because the trunk code has changed a lot).
  90 In that case, it's helpful if you can apply the change to both trunk
  91 and branch yourself (when committing the branch change, indicate
  92 in the commit log that it should not be merged to the trunk; see below).
  93
  94 * Installing changes from your personal branches.
  95
  96 If your branch has only a single commit, or many different real
  97 commits, it is fine to do a merge.  If your branch has only a very
  98 small number of "real" commits, but several "merge from trunks", it is
  99 preferred that you take your branch's diff, apply it to the trunk, and
 100 commit directly, not merge.  This keeps the history cleaner.
 101
 102 In general, when working on some feature in a separate branch, it is
 103 preferable not to merge from trunk until you are done with the
 104 feature.  Unless you really need some change that was done on the
 105 trunk while you were developing on the branch, you don't really need
 106 those merges; just merge once, when you are done with the feature, and
 107 Bazaar will take care of the rest.  Bazaar is much better in this than
 108 CVS, so interim merges are unnecessary.
 109
 110 Or use shelves; or rebase; or do something else.  See the thread for
 111 yet another fun excursion into the exciting world of version control.
 112
 113 http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00086.html
 114
 115 * Installing changes from gnulib
 116
 117 Some of the files in Emacs are copied from gnulib.  To synchronize
 118 these files from the version of gnulib that you have checked out into
 119 a sibling directory of your branch, type "admin/merge-gnulib"; this
 120 will check out the latest version of gnulib if there is no sibling
 121 directory already.  It is a good idea to run "git status" afterwards,
 122 so that if a gnulib module added a file, you can record the new file
 123 using "git add".  After synchronizing from gnulib, do a "make" in the
 124 usual way.
 125
 126 To change the set of gnulib modules, change the GNULIB_MODULES
 127 variable in admin/merge-gnulib before running it.
 128
 129 If you remove a gnulib module, or if a gnulib module
 130 removes a file, then remove the corresponding files by hand.
 131
 132 * Backporting a bug-fix from the trunk to a branch (e.g. "emacs-24").
 133
 134 Indicate in the commit log that there is no need to merge the commit
 135 to the trunk, e.g. start the commit message with "Backport:".  This is
 136 helpful for the person merging the release branch to the trunk.
 137
 138 http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00262.html
 139
 140 * How to merge changes from emacs-24 to trunk
 141
 142 [The section on git merge procedure has not yet been written]
 143
 144 Inspect the change log entries (e.g. in case too many entries have been
 145 included or whitespace between entries needs fixing). If someone made
 146 multiple change log entries on different days in the branch, you may
 147 wish to collapse them all to a single entry for that author in the
 148 trunk (because in the trunk they all appear under the same date).
 149 Obviously, if there are multiple changes to the same file by different
 150 authors, don't break the logical ordering in doing this.
 151
 152 You may see conflicts in autoload md5sums in comments.  Strictly
 153 speaking, the right thing to do is merge everything else, resolve the
 154 conflict by choosing either the trunk or branch version, then run
 155 `make -C lisp autoloads' to update the md5sums to the correct trunk
 156 value before committing.
 157
 158 * Re-adding a file that has been removed from the repository
 159
 160 Let's suppose you've done:
 161
 162 git rm file; git commit -a
 163
 164 You can just restore a copy of the file and then re-add it;
 165 git does not have per-file history so this will not harm
 166 anything.
 167
 168 Alternatively, you can do
 169
 170 git revert XXXXX
 171
 172 where XXXXX is the hash of the commit in which file was removed.
 173 This backs out the entire changeset the deletion was part of,
 174 which is often more appropriate.
 175
 176 * Undoing a commit (uncommitting)
 177
 178 If you have not pushed the commit, you may be able to use `git reset
 179 --hard' with a hash argument to revert the your local repo copy to the
 180 pre-commit state.
 181
 182 If you have pushed  commit, resetting will be ineffective because it
 183 will only vanish the commit in your local copy.  Instead, use `git
 184 revert', giving it the commit ID as argument. This will create a
 185 new commit that backs out the change. Then push that.
 186
 187 Note that git will generate a log message for the revert that includes
 188 a git hash.  Please edit this to refer to the commit by the first line
 189 of its log comment, or by committer and date, or by something else
 190 that is not the hash.  As noted previously, it is best to avoid hashes
 191 in comments in case we someday have to change version-control systems
 192 again.
 193
 194 * Bisecting
 195
 196 This is a semi-automated way to find the revision that introduced a bug.
 197 Browse `git help bisect' for technical instructions.