code.delx.au - gnu-emacs/blob - admin/notes/repo

   1 NOTES ON COMMITTING TO EMACS'S REPOSITORY    -*- outline -*-
   2
   3 ** elpa
   4
   5 This branch does not contain a copy of Emacs, but of the Emacs Lisp
   6 package archive (elpa.gnu.org).  See admin/notes/elpa for further
   7 explanation, and the README file in the branch for usage
   8 instructions.
   9
  10 * Installing changes from your personal branches.
  11
  12 If your branch has only a single commit, or many different real
  13 commits, it is fine to do a merge.  If your branch has only a very
  14 small number of "real" commits, but several "merge from trunks", it is
  15 preferred that you take your branch's diff, apply it to the trunk, and
  16 commit directly, not merge.  This keeps the history cleaner.
  17
  18 In general, when working on some feature in a separate branch, it is
  19 preferable not to merge from trunk until you are done with the
  20 feature.  Unless you really need some change that was done on the
  21 trunk while you were developing on the branch, you don't really need
  22 those merges; just merge once, when you are done with the feature, and
  23 Bazaar will take care of the rest.  Bazaar is much better in this than
  24 CVS, so interim merges are unnecessary.
  25
  26 Or use shelves; or rebase; or do something else.  See the thread for
  27 yet another fun excursion into the exciting world of version control.
  28
  29 http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00086.html
  30
  31 * Installing changes from gnulib
  32
  33 Some of the files in Emacs are copied from gnulib.  To synchronize
  34 these files from the version of gnulib that you have checked out into
  35 a sibling directory of your branch, type "admin/merge-gnulib"; this
  36 will check out the latest version of gnulib if there is no sibling
  37 directory already.  It is a good idea to run "git status" afterwards,
  38 so that if a gnulib module added a file, you can record the new file
  39 using "git add".  After synchronizing from gnulib, do a "make" in the
  40 usual way.
  41
  42 To change the set of gnulib modules, change the GNULIB_MODULES
  43 variable in admin/merge-gnulib before running it.
  44
  45 If you remove a gnulib module, or if a gnulib module
  46 removes a file, then remove the corresponding files by hand.
  47
  48 * How to merge changes from emacs-24 to trunk
  49
  50 [The section on git merge procedure has not yet been written]
  51
  52 Inspect the change log entries (e.g. in case too many entries have been
  53 included or whitespace between entries needs fixing). If someone made
  54 multiple change log entries on different days in the branch, you may
  55 wish to collapse them all to a single entry for that author in the
  56 trunk (because in the trunk they all appear under the same date).
  57 Obviously, if there are multiple changes to the same file by different
  58 authors, don't break the logical ordering in doing this.
  59
  60 You may see conflicts in autoload md5sums in comments.  Strictly
  61 speaking, the right thing to do is merge everything else, resolve the
  62 conflict by choosing either the trunk or branch version, then run
  63 `make -C lisp autoloads' to update the md5sums to the correct trunk
  64 value before committing.
  65
  66 * Re-adding a file that has been removed from the repository
  67
  68 Let's suppose you've done:
  69
  70 git rm file; git commit -a
  71
  72 You can just restore a copy of the file and then re-add it;
  73 git does not have per-file history so this will not harm
  74 anything.
  75
  76 Alternatively, you can do
  77
  78 git revert XXXXX
  79
  80 where XXXXX is the hash of the commit in which file was removed.
  81 This backs out the entire changeset the deletion was part of,
  82 which is often more appropriate.
  83
  84 * Undoing a commit (uncommitting)
  85
  86 If you have not pushed the commit, you may be able to use `git reset
  87 --hard' with a hash argument to revert the your local repo copy to the
  88 pre-commit state.
  89
  90 If you have pushed  commit, resetting will be ineffective because it
  91 will only vanish the commit in your local copy.  Instead, use `git
  92 revert', giving it the commit ID as argument. This will create a
  93 new commit that backs out the change. Then push that.
  94
  95 Note that git will generate a log message for the revert that includes
  96 a git hash.  Please edit this to refer to the commit by the first line
  97 of its log comment, or by committer and date, or by something else
  98 that is not the hash.  As noted previously, it is best to avoid hashes
  99 in comments in case we someday have to change version-control systems
 100 again.
 101
 102 * Bisecting
 103
 104 This is a semi-automated way to find the revision that introduced a bug.
 105 Browse `git help bisect' for technical instructions.