code.delx.au - gnu-emacs/blob - 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, by
  86 including the phrase "Not to be merged to master", or any other phrase
  87 that matches "merge").
  88
  89 * Installing changes from your personal branches.
  90
  91 If your branch has only a single commit, or many different real
  92 commits, it is fine to do a merge.  If your branch has only a very
  93 small number of "real" commits, but several "merge from trunks", it is
  94 preferred that you take your branch's diff, apply it to the trunk, and
  95 commit directly, not merge.  This keeps the history cleaner.
  96
  97 In general, when working on some feature in a separate branch, it is
  98 preferable not to merge from trunk until you are done with the
  99 feature.  Unless you really need some change that was done on the
 100 trunk while you were developing on the branch, you don't really need
 101 those merges; just merge once, when you are done with the feature, and
 102 Bazaar will take care of the rest.  Bazaar is much better in this than
 103 CVS, so interim merges are unnecessary.
 104
 105 Or use shelves; or rebase; or do something else.  See the thread for
 106 yet another fun excursion into the exciting world of version control.
 107
 108 http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00086.html
 109
 110 * Installing changes from gnulib
 111
 112 Some of the files in Emacs are copied from gnulib.  To synchronize
 113 these files from the version of gnulib that you have checked out into
 114 a sibling directory of your branch, type "admin/merge-gnulib"; this
 115 will check out the latest version of gnulib if there is no sibling
 116 directory already.  It is a good idea to run "git status" afterwards,
 117 so that if a gnulib module added a file, you can record the new file
 118 using "git add".  After synchronizing from gnulib, do a "make" in the
 119 usual way.
 120
 121 To change the set of gnulib modules, change the GNULIB_MODULES
 122 variable in admin/merge-gnulib before running it.
 123
 124 If you remove a gnulib module, or if a gnulib module
 125 removes a file, then remove the corresponding files by hand.
 126
 127 * Backporting a bug-fix from the trunk to a branch (e.g. "emacs-24").
 128
 129 Indicate in the commit log that there is no need to merge the commit
 130 to the trunk, e.g. start the commit message with "Backport:".  This is
 131 helpful for the person merging the release branch to the trunk.
 132
 133 http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00262.html
 134
 135 * How to merge changes from emacs-24 to trunk
 136
 137 [The section on git merge procedure has not yet been written]
 138
 139 Inspect the change log entries (e.g. in case too many entries have been
 140 included or whitespace between entries needs fixing). If someone made
 141 multiple change log entries on different days in the branch, you may
 142 wish to collapse them all to a single entry for that author in the
 143 trunk (because in the trunk they all appear under the same date).
 144 Obviously, if there are multiple changes to the same file by different
 145 authors, don't break the logical ordering in doing this.
 146
 147 You may see conflicts in autoload md5sums in comments.  Strictly
 148 speaking, the right thing to do is merge everything else, resolve the
 149 conflict by choosing either the trunk or branch version, then run
 150 `make -C lisp autoloads' to update the md5sums to the correct trunk
 151 value before committing.
 152
 153 * Re-adding a file that has been removed from the repository
 154
 155 Let's suppose you've done:
 156
 157 git rm file; git commit -a
 158
 159 You can just restore a copy of the file and then re-add it;
 160 git does not have per-file history so this will not harm
 161 anything.
 162
 163 Alternatively, you can do
 164
 165 git revert XXXXX
 166
 167 where XXXXX is the hash of the commit in which file was removed.
 168 This backs out the entire changeset the deletion was part of,
 169 which is often more appropriate.
 170
 171 * Undoing a commit (uncommitting)
 172
 173 If you have not pushed the commit, you may be able to use `git reset
 174 --hard' with a hash argument to revert the your local repo copy to the
 175 pre-commit state.
 176
 177 If you have pushed  commit, resetting will be ineffective because it
 178 will only vanish the commit in your local copy.  Instead, use `git
 179 revert', giving it the commit ID as argument. This will create a
 180 new commit that backs out the change. Then push that.
 181
 182 Note that git will generate a log message for the revert that includes
 183 a git hash.  Please edit this to refer to the commit by the first line
 184 of its log comment, or by committer and date, or by something else
 185 that is not the hash.  As noted previously, it is best to avoid hashes
 186 in comments in case we someday have to change version-control systems
 187 again.
 188
 189 * Bisecting
 190
 191 This is a semi-automated way to find the revision that introduced a bug.
 192 Browse `git help bisect' for technical instructions.