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