admin/notes/repo

   1 NOTES ON COMMITTING TO EMACS'S REPOSITORY    -*- outline -*-
   2
   3 * Install changes only on one branch, let them get merged elsewhere if needed.
   4
   5 In particular, install bug-fixes only on the release branch (if there
   6 is one) and let them get synced to the master; do not install them by
   7 hand on the master as well.  E.g. if there is an active "emacs-24" branch
   8 and you have a bug-fix appropriate for the next emacs-24.x release,
   9 install it only on the emacs-24 branch, not on the master as well.
  10
  11 Installing things manually into more than one branch makes merges more
  12 difficult.
  13
  14 https://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01124.html
  15
  16 The exception is, if you know that the change will be difficult to
  17 merge to the master (eg because the master code has changed a lot).
  18 In that case, it's helpful if you can apply the change to both master
  19 and branch yourself (when committing the branch change, indicate
  20 in the commit log that it should not be merged to the master, by
  21 including the phrase "Not to be merged to master", or any other phrase
  22 that matches "merge").
  23
  24 * Installing changes from your personal branches.
  25
  26 If your branch has only a single commit, or many different real
  27 commits, it is fine to do a merge.  If your branch has only a very
  28 small number of "real" commits, but several "merge from masters", it is
  29 preferred that you take your branch's diff, apply it to the master, and
  30 commit directly, not merge.  This keeps the history cleaner.
  31
  32 In general, when working on some feature in a separate branch, it is
  33 preferable not to merge from master until you are done with the
  34 feature.  Unless you really need some change that was done on the
  35 master while you were developing on the branch, you don't really need
  36 those merges; just merge once, when you are done with the feature, and
  37 Git will take care of the rest.  Git is much better in this than CVS,
  38 so interim merges are unnecessary.
  39
  40 Or use shelves; or rebase; or do something else.  See the thread for
  41 yet another fun excursion into the exciting world of version control.
  42
  43 https://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00086.html
  44
  45 * Installing changes from gnulib
  46
  47 Some of the files in Emacs are copied from gnulib.  To synchronize
  48 these files from the version of gnulib that you have checked out into
  49 a sibling directory of your branch, type "admin/merge-gnulib"; this
  50 will check out the latest version of gnulib if there is no sibling
  51 directory already.  It is a good idea to run "git status" afterwards,
  52 so that if a gnulib module added a file, you can record the new file
  53 using "git add".  After synchronizing from gnulib, do a "make" in the
  54 usual way.
  55
  56 To change the set of gnulib modules, change the GNULIB_MODULES
  57 variable in admin/merge-gnulib before running it.
  58
  59 If you remove a gnulib module, or if a gnulib module
  60 removes a file, then remove the corresponding files by hand.
  61
  62 * How to merge changes from emacs-24 to master
  63
  64 [The section on git merge procedure has not yet been written.]
  65
  66 You may see conflicts in autoload md5sums in comments.  Strictly
  67 speaking, the right thing to do is merge everything else, resolve the
  68 conflict by choosing either the master or branch version, then run
  69 'make -C lisp autoloads' to update the md5sums to the correct master
  70 value before committing.
  71
  72 * Re-adding a file that has been removed from the repository
  73
  74 Let's suppose you've done:
  75
  76 git rm file; git commit -a
  77
  78 You can just restore a copy of the file and then re-add it;
  79 git does not have per-file history so this will not harm
  80 anything.
  81
  82 Alternatively, you can do
  83
  84 git revert XXXXX
  85
  86 where XXXXX is the hash of the commit in which file was removed.
  87 This backs out the entire changeset the deletion was part of,
  88 which is often more appropriate.
  89
  90 * Undoing a commit (uncommitting)
  91
  92 If you have not pushed the commit, you may be able to use 'git reset
  93 --hard' with a hash argument to revert the your local repo copy to the
  94 pre-commit state.
  95
  96 If you have pushed  commit, resetting will be ineffective because it
  97 will only vanish the commit in your local copy.  Instead, use 'git
  98 revert', giving it the commit ID as argument. This will create a
  99 new commit that backs out the change. Then push that.
 100
 101 Note that git will generate a log message for the revert that includes
 102 a git hash.  Please edit this to refer to the commit by the first line
 103 of its log comment, or by committer and date, or by something else
 104 that is not the hash.  As noted previously, it is best to avoid hashes
 105 in comments in case we someday have to change version-control systems
 106 again.
 107
 108 * Bisecting
 109
 110 This is a semi-automated way to find the revision that introduced a bug.
 111 Browse 'git help bisect' for technical instructions.
 112
 113 * Maintaining ChangeLog history
 114
 115 Older ChangeLog entries are kept in history files named ChangeLog.1,
 116 ChangeLog.2, etc., and can be edited just as any other source files
 117 can.  Newer ChangeLog entries are stored in the repository as commit
 118 messages, which cannot be edited directly.
 119
 120 'make ChangeLog' copies newer ChangeLog entries into a file
 121 'ChangeLog' that is intended to be put into the distribution tarball.
 122 This ChangeLog file is not put into the repository.
 123
 124 'make change-history' copies all newer ChangeLog entries into the
 125 start of the newest ChangeLog history file.  These ChangeLog entries
 126 are thereafter considered to be old, so later uses of 'make ChangeLog'
 127 and/or 'make change-history' will no longer copy the entries.  To
 128 alter ChangeLog history, run 'make change-history', then edit
 129 the ChangeLog history files manually and commit your changes.