mirror of
git://git.sv.gnu.org/emacs.git
synced 2026-01-06 11:50:51 -08:00
06264b3d24
* CONTRIBUTE: improve; add explicit web references, move some info from admin/notes/* here. * INSTALL.REPO: You can't "just run make" after a clean checkout. * admin/notes/commits: deleted; merged into ./CONTRIBUTE * admin/notes/repo: move commit, branch info into ./CONTRIBUTE
105 lines
4.3 KiB
Text
105 lines
4.3 KiB
Text
NOTES ON COMMITTING TO EMACS'S REPOSITORY -*- outline -*-
|
|
|
|
** 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.
|
|
|
|
* 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.
|
|
|
|
* How to merge changes from emacs-24 to trunk
|
|
|
|
[The section on git merge procedure has not yet been written]
|
|
|
|
Inspect the change log entries (e.g. in case too many entries have been
|
|
included or whitespace between entries needs fixing). If someone made
|
|
multiple change log 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.
|