repo 5.63 KB
Newer Older
1
NOTES ON COMMITTING TO EMACS'S REPOSITORY    -*- outline -*-
Glenn Morris's avatar
Glenn Morris committed
2

3 4 5 6 7 8 9
** elpa

This branch does not contain a copy of Emacs, but of the Emacs Lisp
package archive (elpa.gnu.org).  See admin/notes/elpa for further
explanation, and the README file in the branch for usage
instructions.

Glenn Morris's avatar
Glenn Morris committed
10
* Install changes only on one branch, let them get merged elsewhere if needed.
11

Glenn Morris's avatar
Glenn Morris committed
12
In particular, install bug-fixes only on the release branch (if there
13 14
is one) and let them get synced to the master; do not install them by
hand on the master as well.  E.g. if there is an active "emacs-24" branch
15
and you have a bug-fix appropriate for the next emacs-24.x release,
16
install it only on the emacs-24 branch, not on the master as well.
Glenn Morris's avatar
Glenn Morris committed
17 18 19 20 21 22

Installing things manually into more than one branch makes merges more
difficult.

http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01124.html

23
The exception is, if you know that the change will be difficult to
24 25
merge to the master (eg because the master code has changed a lot).
In that case, it's helpful if you can apply the change to both master
26
and branch yourself (when committing the branch change, indicate
27
in the commit log that it should not be merged to the master, by
28 29
including the phrase "Not to be merged to master", or any other phrase
that matches "merge").
30

Glenn Morris's avatar
Glenn Morris committed
31
* Installing changes from your personal branches.
32

Glenn Morris's avatar
Glenn Morris committed
33 34
If your branch has only a single commit, or many different real
commits, it is fine to do a merge.  If your branch has only a very
35 36
small number of "real" commits, but several "merge from masters", it is
preferred that you take your branch's diff, apply it to the master, and
Glenn Morris's avatar
Glenn Morris committed
37 38
commit directly, not merge.  This keeps the history cleaner.

39
In general, when working on some feature in a separate branch, it is
40
preferable not to merge from master until you are done with the
41
feature.  Unless you really need some change that was done on the
42
master while you were developing on the branch, you don't really need
43 44 45 46
those merges; just merge once, when you are done with the feature, and
Bazaar will take care of the rest.  Bazaar is much better in this than
CVS, so interim merges are unnecessary.

Glenn Morris's avatar
Glenn Morris committed
47 48 49 50
Or use shelves; or rebase; or do something else.  See the thread for
yet another fun excursion into the exciting world of version control.

http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00086.html
51

52
* Installing changes from gnulib
53

54 55
Some of the files in Emacs are copied from gnulib.  To synchronize
these files from the version of gnulib that you have checked out into
56
a sibling directory of your branch, type "admin/merge-gnulib"; this
57
will check out the latest version of gnulib if there is no sibling
Eric S. Raymond's avatar
Eric S. Raymond committed
58
directory already.  It is a good idea to run "git status" afterwards,
59
so that if a gnulib module added a file, you can record the new file
Eric S. Raymond's avatar
Eric S. Raymond committed
60
using "git add".  After synchronizing from gnulib, do a "make" in the
61 62 63
usual way.

To change the set of gnulib modules, change the GNULIB_MODULES
64
variable in admin/merge-gnulib before running it.
65

66
If you remove a gnulib module, or if a gnulib module
67 68
removes a file, then remove the corresponding files by hand.

69
* How to merge changes from emacs-24 to master
70

71
[The section on git merge procedure has not yet been written.]
72 73 74

You may see conflicts in autoload md5sums in comments.  Strictly
speaking, the right thing to do is merge everything else, resolve the
75
conflict by choosing either the master or branch version, then run
76
'make -C lisp autoloads' to update the md5sums to the correct master
77
value before committing.
78 79 80

* Re-adding a file that has been removed from the repository

Eric S. Raymond's avatar
Eric S. Raymond committed
81
Let's suppose you've done:
82

Eric S. Raymond's avatar
Eric S. Raymond committed
83
git rm file; git commit -a
84

Eric S. Raymond's avatar
Eric S. Raymond committed
85 86 87
You can just restore a copy of the file and then re-add it;
git does not have per-file history so this will not harm
anything.
88

Eric S. Raymond's avatar
Eric S. Raymond committed
89
Alternatively, you can do
90

Eric S. Raymond's avatar
Eric S. Raymond committed
91
git revert XXXXX
92

Eric S. Raymond's avatar
Eric S. Raymond committed
93 94 95
where XXXXX is the hash of the commit in which file was removed.
This backs out the entire changeset the deletion was part of,
which is often more appropriate.
96

Glenn Morris's avatar
Glenn Morris committed
97 98
* Undoing a commit (uncommitting)

99
If you have not pushed the commit, you may be able to use 'git reset
Eric S. Raymond's avatar
Eric S. Raymond committed
100 101
--hard' with a hash argument to revert the your local repo copy to the
pre-commit state.
Glenn Morris's avatar
Glenn Morris committed
102

Eric S. Raymond's avatar
Eric S. Raymond committed
103
If you have pushed  commit, resetting will be ineffective because it
104
will only vanish the commit in your local copy.  Instead, use 'git
Eric S. Raymond's avatar
Eric S. Raymond committed
105 106
revert', giving it the commit ID as argument. This will create a
new commit that backs out the change. Then push that.
Glenn Morris's avatar
Glenn Morris committed
107

Eric S. Raymond's avatar
Eric S. Raymond committed
108 109 110 111 112 113
Note that git will generate a log message for the revert that includes
a git hash.  Please edit this to refer to the commit by the first line
of its log comment, or by committer and date, or by something else
that is not the hash.  As noted previously, it is best to avoid hashes
in comments in case we someday have to change version-control systems
again.
114 115 116 117

* Bisecting

This is a semi-automated way to find the revision that introduced a bug.
118
Browse 'git help bisect' for technical instructions.
119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136

* Maintaining ChangeLog history

Older ChangeLog entries are kept in history files named ChangeLog.1,
ChangeLog.2, etc., and can be edited just as any other source files
can.  Newer ChangeLog entries are stored in the repository as commit
messages, which cannot be edited directly.

'make ChangeLog' copies newer ChangeLog entries into a file
'ChangeLog' that is intended to be put into the distribution tarball.
This ChangeLog file is not put into the repository.

'make change-history' copies all newer ChangeLog entries into the
start of the newest ChangeLog history file.  These ChangeLog entries
are thereafter considered to be old, so later uses of 'make ChangeLog'
and/or 'make change-history' will no longer copy the entries.  To
alter ChangeLog history, run 'make change-history', then edit
the ChangeLog history files manually and commit your changes.