admin/notes/repo

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