mirror of
git://git.sv.gnu.org/emacs.git
synced 2026-01-14 15:30:29 -08:00
7148318abc
All bzr revision IDS, and all CVS revision IDs for which a commit could be identified, were changed to time-date!committer version stamps. All .cvsignore files in the history became .gitignore files. Fixes-bug annotations from bzr were copied into the corresponding commit comments. (The first .cvsignore commit was 1999-09-30T14:07:54Z!fx@gnu.org>. The last CVS commit was <2009-12-27T08:11:12Z!cyd@stupidchicken.com>) Committer/author email addresses are generally correct for the transition day, not necessarily when the commit was originally made.
169 lines
6.8 KiB
Text
169 lines
6.8 KiB
Text
NOTES ON COMMITTING TO EMACS'S REPOSITORY -*- outline -*-
|
|
|
|
* Use DVCS commenting conventions
|
|
|
|
Commits should follow the conventions used in all modern distributed
|
|
version-control systems. That is, they should consist of
|
|
|
|
- A self-contained topic line, preferably no more than 75 chars long.
|
|
|
|
- If other content follows the topic line, there should be a blank
|
|
line separating the two.
|
|
|
|
- Follow the blank line with ChangeLog-like entries for the specific
|
|
changes you made, if any. (As long as Emacs maintains ChangeLog
|
|
files, just copy the entries you made in them to the commit message
|
|
after the blank line.)
|
|
|
|
* Commit to the right branch
|
|
|
|
Development normally takes places on the trunk.
|
|
Sometimes specialized features are developed on separate branches
|
|
before possibly being merged to the trunk.
|
|
|
|
Development is discussed on the emacs-devel mailing list.
|
|
|
|
Sometime before the release of a new major version of Emacs
|
|
a "feature freeze" is imposed on the trunk. No new features may be
|
|
added after this point. This is usually some months before the release.
|
|
|
|
Shortly before the release, a release branch is created, and the
|
|
trunk is then free for development.
|
|
|
|
For example, "emacs-23" for Emacs 23.2 and later, "EMACS_23_1_RC" for
|
|
23.1, "EMACS_22_BASE" for 22.x, and "EMACS_21_1_RC" for 21.x.
|
|
|
|
Consult emacs-devel for exactly what kinds of changes are allowed
|
|
on what branch at any time.
|
|
|
|
** 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.
|
|
|
|
* Install changes only on one branch, let them get merged elsewhere if needed.
|
|
|
|
In particular, install bug-fixes only on the release branch (if there
|
|
is one) and let them get synced to the trunk; do not install them by
|
|
hand on the trunk as well. E.g. if there is an active "emacs-24" branch
|
|
and you have a bug-fix appropriate for the next emacs-24.x release,
|
|
install it only on the emacs-24 branch, not on the trunk as well.
|
|
|
|
Installing things manually into more than one branch makes merges more
|
|
difficult.
|
|
|
|
http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01124.html
|
|
|
|
The exception is, if you know that the change will be difficult to
|
|
merge to the trunk (eg because the trunk code has changed a lot).
|
|
In that case, it's helpful if you can apply the change to both trunk
|
|
and branch yourself (when committing the branch change, indicate
|
|
in the commit log that it should not be merged to the trunk; see below).
|
|
|
|
* Installing changes from your personal branches.
|
|
|
|
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
|
|
small number of "real" commits, but several "merge from trunks", it is
|
|
preferred that you take your branch's diff, apply it to the trunk, and
|
|
commit directly, not merge. This keeps the history cleaner.
|
|
|
|
In general, when working on some feature in a separate branch, it is
|
|
preferable not to merge from trunk until you are done with the
|
|
feature. Unless you really need some change that was done on the
|
|
trunk while you were developing on the branch, you don't really need
|
|
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.
|
|
|
|
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
|
|
|
|
* Installing changes from gnulib
|
|
|
|
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
|
|
a sibling directory of your branch, type "admin/merge-gnulib"; this
|
|
will check out the latest version of gnulib if there is no sibling
|
|
directory already. It is a good idea to run "git status" afterwards,
|
|
so that if a gnulib module added a file, you can record the new file
|
|
using "git add". After synchronizing from gnulib, do a "make" in the
|
|
usual way.
|
|
|
|
To change the set of gnulib modules, change the GNULIB_MODULES
|
|
variable in admin/merge-gnulib before running it.
|
|
|
|
If you remove a gnulib module, or if a gnulib module
|
|
removes a file, then remove the corresponding files by hand.
|
|
|
|
* Backporting a bug-fix from the trunk to a branch (e.g. "emacs-24").
|
|
|
|
Indicate in the commit log that there is no need to merge the commit
|
|
to the trunk, e.g. start the commit message with "Backport:". This is
|
|
helpful for the person merging the release branch to the trunk.
|
|
|
|
http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00262.html
|
|
|
|
* How to merge changes from emacs-24 to trunk
|
|
|
|
[The section on git merge procedure has not yet been written]
|
|
|
|
Inspect the ChangeLog entries (e.g. in case too many entries have been
|
|
included or whitespace between entries needs fixing). If someone made
|
|
multiple ChangeLog entries on different days in the branch, you may
|
|
wish to collapse them all to a single entry for that author in the
|
|
trunk (because in the trunk they all appear under the same date).
|
|
Obviously, if there are multiple changes to the same file by different
|
|
authors, don't break the logical ordering in doing this.
|
|
|
|
You may see conflicts in autoload md5sums in comments. Strictly
|
|
speaking, the right thing to do is merge everything else, resolve the
|
|
conflict by choosing either the trunk or branch version, then run
|
|
`make -C lisp autoloads' to update the md5sums to the correct trunk
|
|
value before committing.
|
|
|
|
* Re-adding a file that has been removed from the repository
|
|
|
|
Let's suppose you've done:
|
|
|
|
git rm file; git commit -a
|
|
|
|
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.
|
|
|
|
Alternatively, you can do
|
|
|
|
git revert XXXXX
|
|
|
|
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.
|
|
|
|
* Undoing a commit (uncommitting)
|
|
|
|
If you have not pushed the commit, you may be able to use `git reset
|
|
--hard' with a hash argument to revert the your local repo copy to the
|
|
pre-commit state.
|
|
|
|
If you have pushed commit, resetting will be ineffective because it
|
|
will only vanish the commit in your local copy. Instead, use `git
|
|
revert', giving it the commit ID as argument. This will create a
|
|
new commit that backs out the change. Then push that.
|
|
|
|
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.
|
|
|
|
* Bisecting
|
|
|
|
This is a semi-automated way to find the revision that introduced a bug.
|
|
Browse `git help bisect' for technical instructions.
|
|
|