mirrors/emacs
1
Fork 0
mirror of git://git.sv.gnu.org/emacs.git synced 2025-12-15 10:30:25 -08:00
Code Issues Projects Releases Wiki Activity

Git transition patch

Browse source 
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.
This commit is contained in:
Eric S. Raymond 2014-11-11 13:28:05 -05:00
parent 7611d85a45
commit ac03795dc4
10 changed files with 1072 additions and 1358 deletions
Download patch file Download diff file Expand all files Collapse all files

17
ChangeLog
View file

@ -1,3 +1,20 @@
2014-11-11 Eric S. Raymond <esr@thyrsus.com>
* Makefile.in: git transition - set VCWITNESS appropriately for git.
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 comit was originally
made.
2014-11-05 Glenn Morris <rgm@gnu.org>
* Makefile.in (install-info, uninstall): Restore pre-2012-12-13

7
Makefile.in
View file

@ -374,12 +374,17 @@ lib lib-src lisp nt: Makefile FRC
# all preloaded elisp files, and only then dump the actual src/emacs, which
# is not wrong, but is overkill in 99.99% of the cases.
#
# Ideally, VCSWITNESS should be a file that is modified whenever the
# repository registers a commit from either a local checkin or a
# repository pull. In git there is no single file that guarantees
# this, but the local log for the current head should be close enough.
#
# Note the use of single quotes in the value of vcswitness.
# This passes an unexpanded $srcdir to src's Makefile, which then
# expands it using its own value of srcdir (which points to the
# source directory of src/).
src: Makefile FRC
dirstate='.bzr/checkout/dirstate'; \
dirstate='.git/logs/HEAD'; \
vcswitness='$$(srcdir)/../'$$dirstate; \
[ -r "$(srcdir)/$$dirstate" ] || vcswitness=''; \
cd $@ || exit; \

6
admin/ChangeLog
View file

@ -1,3 +1,9 @@
2014-11-11 Eric S. Raymond <esr@thyrsus.com>
* make-tarball.txt, update-copyright, admin/notes/bugtracker,
admin/notes/tags, admin/update-copyright, admin/update_autogen:
admin/repo.notes: git transition.
2014-11-09 Eli Zaretskii <eliz@gnu.org>
* unidata/Makefile.in (${top_srcdir}/src/macuvs.h): Use

16
admin/make-tarball.txt
View file

@ -7,8 +7,7 @@ Steps to take before starting on the first pretest in any release sequence:
0. The release branch (e.g. emacs-24) should already have been made
and you should use it for all that follows. Diffs from this
branch should be going to the emacs-diffs mailing list (see
admin/notes/bzr section on bzr-email plugin).
branch should be going to the emacs-diffs mailing list.
1. Decide on versions of automake and autoconf, and ensure you will
have them available for the duration of the release process.
@ -24,8 +23,8 @@ Steps to take before starting on the first pretest in any release sequence:
General steps (for each step, check for possible errors):
1. `bzr update' (for a bound branch), or `bzr pull'.
bzr status # check for locally modified files
1. git pull # fetch from the repository
git status # check for locally modified files
2. Regenerate the etc/AUTHORS file:
M-: (require 'authors) RET
@ -66,9 +65,8 @@ General steps (for each step, check for possible errors):
5. Copy lisp/loaddefs.el to lisp/ldefs-boot.el.
Commit etc/AUTHORS, lisp/ldefs-boot.el, and the files changed
by M-x set-version. Use a commit log message that bzrmerge.el
will ignore (eg "Bump version...").
For a release, also commit the ChangeLog files in all directories.
by M-x set-version. For a release, also commit the ChangeLog
files in all directories.
If someone else made a commit between step 1 and now,
you need to repeat from step 4 onwards. (You can commit the files
@ -84,7 +82,7 @@ General steps (for each step, check for possible errors):
If this is the first pretest of a major release, just comparing
with the previous release may overlook many new files. You can try
something like `find . | sort' in a clean bzr tree, and compare the
something like `find . | sort' in a clean repository, and compare the
results against the new tar contents.
7. tar -xf emacs-NEW.tar; cd emacs-NEW
@ -96,7 +94,7 @@ General steps (for each step, check for possible errors):
M-x ediff. Especially check that Info files aren't built, and that
no autotools (autoconf etc) run.
8. cd EMACS_ROOT_DIR && bzr tag TAG
8. cd EMACS_ROOT_DIR && git tag TAG
TAG is emacs-XX.Y.ZZ for a pretest, emacs-XX.Y for a release.
9. Decide what compression schemes to offer.

38
admin/notes/bugtracker
View file

@ -487,44 +487,6 @@ the bug web-pages.
http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg00440.html
** Bazaar stuff
*** You can use `bzr commit --fixes debbugs:123' to mark that a commit fixes
Emacs bug 123. You will first need to add a line to one of your
configuration files, ~/.bazaar/bazaar.conf or ~/.bazaar/locations.conf:
bugtracker_debbugs_url = http://debbugs.gnu.org/{id}
Here "{id}" is a literal string, a placeholder that will be replaced
by the bug number you specify after `--fixes debbugs:' in the bzr
command line (123 in the example above).
In the bazaar.conf file, this setting should go into the [DEFAULT]
section.
In the locations.conf file, it should go into the branch-specific
configuration section for the branch where you want this to be in
effect. For example, if you want this to be in effect for the branch
located at `/home/projects/emacs/trunk', you need to have this in your
~/.bazaar/locations.conf file:
[/home/projects/emacs/trunk]
bugtracker_debbugs_url = http://debbugs.gnu.org/{id}
If you want to use this in all Emacs branches whose common parent is
`/home/projects/emacs', put the setting in the [/home/projects/emacs]
section. See "bzr help configuration" for more information about
the *.conf files, their location and formats. See "bzr help bugs" for
more information about the bugtracker_debbugs_url setting.
See also log-edit-rewrite-fixes in .dir-locals.el.
Note that all this does is add some metadata to the commit, it doesn't
actually mark the bug as closed in the tracker. You can see this
information with `bzr log', and it will show up as a link in a recent
loggerhead installation, or with some of the graphical frontends to
`bzr log'.
** Gnus-specific voodoo
*** Put point on a bug-number and try: M-x gnus-read-ephemeral-emacs-bug-group

344
admin/notes/repo
View file

@ -17,10 +17,6 @@ version-control systems. That is, they should consist of
* Commit to the right branch
You can view the available Emacs branches at
http://bzr.savannah.gnu.org/r/emacs/
Development normally takes places on the trunk.
Sometimes specialized features are developed on separate branches
before possibly being merged to the trunk.
@ -93,9 +89,9 @@ 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 "bzr status" afterwards,
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 "bzr add". After synchronizing from gnulib, do a "make" in the
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
@ -107,93 +103,22 @@ 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. Anything that matches `bzrmerge-skip-regexp' will do;
eg start the commit message with "Backport:". This is helpful for the
person merging the release branch to the trunk.
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 following description uses bound branches, presumably it works in
a similar way with unbound ones.
0) (This step is only necessary if using bzr older than 2.4.0.)
Get the bzr changelog_merge plugin:
cd ~/.bazaar/plugins
bzr branch http://bazaar.launchpad.net/~spiv/bzr-changelog-merge/trunk changelog_merge
This plugin should make merging ChangeLogs smoother. It merges new
entries to the top of the file, rather than trying to fit them in
mid-way through. Newer versions of the plugin should also be able to
deal with changes to *old* ChangeLog entries, that should not be
floated to the head of the file (see launchpad#723968).
It is included in bzr from 2.4.0 onwards, so remember to delete the
copy in ~/.bazaar if you upgrade bzr.
Maybe the default Emacs behavior without this plugin is better,
though, it's not clear yet.
1) Get clean, up-to-date copies of the emacs-24 and trunk branches.
Check for any uncommitted changes with bzr status.
2) M-x cd /path/to/trunk
The first time only, do this:
cd .bzr/branch
Add the following line to branch.conf:
changelog_merge_files = ChangeLog
3) load admin/bzrmerge.el
4) M-x bzrmerge RET /path/to/emacs-24 RET
It will prompt about revisions that should be skipped, based on the
regexp in bzrmerge-missing. If there are more revisions that you know
need skipping, you'll have to do that by hand.
5) It will stop if there are any conflicts. Resolve them.
Using smerge-mode, there are menu items to skip to the next conflict,
and to take either the trunk, branch, or both copies.
6) After resolving all conflicts, you might need to run the bzmerge
command again if there are more revisions still to merge.
Do not commit (or exit Emacs) until you have run bzrmerge to completion.
Before committing, check bzr status and bzr diff output.
If you have run bzrmerge enough times, the "pending merge tip" in bzr
status should be the last revision from the emacs-24 branch, and
bzr status -v should show all the revisions you expect to merge.
(Note that it will also show "skipped" revisions. This is expected,
and is due to a technical limitation of bzr. The log data for those
revisions gets merged, the actual changes themselves do not.
http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00609.html )
Notes:
1) If a file is modified in emacs-24, and deleted in the trunk, you
get a "contents conflict". Assuming the changes don't need to be in
the trunk at all, use `bzr resolve path/to/file --take-this' to keep the
trunk version. Prior to bzr 2.2.3, this may fail. You can just
delete the .OTHER etc files by hand and use bzr resolve path/to/file.
* Sanity-checking branch merges
[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). bzrmerge tries
to fix up the dates to today's date, but it only does this where there
are conflicts. If you used the changelog_merge plugin, there won't be
any conflicts, and (at time of writing) you will need to adjust dates
by hand. In any case, 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.
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
@ -203,241 +128,42 @@ value before committing.
* Re-adding a file that has been removed from the repository
It's easy to get this wrong. Let's suppose you've done:
Let's suppose you've done:
bzr remove file; bzr commit
git rm file; git commit -a
and now, sometime later, you realize this was a mistake and file needs
to be brought back. DON'T just do:
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.
bzr add file; bzr commit
Alternatively, you can do
This restores file, but without its history (`bzr log file' will be
very short). This is because file gets re-added with a new file-id
(use `bzr file-id file' to see the id).
git revert XXXXX
Instead of adding the file, try:
bzr revert -rN file; bzr commit
where revision N+1 is the one where file was removed.
You could also try `bzr add --file-ids-from', if you have a copy of
another branch where file still exists.
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)
It is possible to undo/remove a bzr commit (ie, to uncommit).
Only do this if you really, really, need to. For example, if you
somehow made a commit that triggers a bug in bzr itself.
Don't do it because you made a typo in a commit or the log.
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 do need to do this, do it as soon as possible, because the
longer you leave it, the more work is involved.
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.
0. First, tell emacs-devel that you are going to do this, and suggest
people not commit anything to the affected branch for the duration.
In the following, replace USER with your Savannah username, and
BRANCH with the name of the branch.
Let's assume that revno 100 is the bad commit, and that there have
been two more commits after that (because nothing is ever easy).
1. Ensure your copy of the branch is up-to-date (for a bound
branch, bzr up; for an unbound branch, bzr pull) and has no local
changes (bzr st).
2. Make a record of the commits you are going to undo:
bzr diff -c 102 > /tmp/102.diff
etc
Also record the commit message, author, and any --fixes information.
3. Most Emacs branches are set up to prevent just this kind of thing.
So we need to disable that protection:
bzr config append_revisions_only=False \
-d bzr+ssh://USER@bzr.savannah.gnu.org/emacs/BRANCH/
4. Undo the commits:
bzr uncommit -r -4
This will show the commits it is going to undo, and prompt you to confirm.
5. If using an unbound branch:
bzr push --overwrite
6. Now, replay the commits you just undid (obviously, fix whatever it
was in the bad commit that caused the problem):
patch -p0 < /tmp/100.diff
bzr commit --author ... --fixes ... -F /tmp/100.log
etc
7. If using an unbound branch:
bzr push
8. Finally, re-enable the branch protection:
bzr config append_revisions_only=True \
-d bzr+ssh://USER@bzr.savannah.gnu.org/emacs/BRANCH/
9. Tell emacs-devel that it is ok to use the branch again.
Anyone with local changes should back them up before doing anything.
For a bound branch, bzr up will convert any of the undone commits to a
pending merge. Just bzr revert these away.
For an unbound branch, bzr pull will complain about diverged branches
and refuse to do anything. Use bzr pull --overwrite.
* Loggerhead
Loggerhead is the bzr tool for viewing a repository over http (similar
to ViewVC). The central version is at http://bzr.savannah.gnu.org/lh/emacs,
but if you just like the way this interface presents data, then if
you have your own copy of the repository, you can operate your own
Loggerhead server in stand-alone mode, and so help to reduce the load
on Savannah:
bzr branch lp:loggerhead ~/.bazaar/plugins/loggerhead
cd /path/to/emacs/bzr
bzr serve --http
You may need to install some Python dependencies to get this command to work.
For example, on RHEL6 I needed:
yum install python-paste python-simplejson
yum --enablerepo=epel install python-simpletal
Then point your web-browser to http://127.0.0.1:8080/ .
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.
First, get the bzr bisect plugin if you do not have it already:
cd ~/.bazaar/plugins
bzr branch lp:bzr-bisect bisect
`bzr help bisect' should work now.
It's probably simplest to make a new copy of the branch to work in
from this point onwards.
Identify the last known "good" revision where the relevant issue is
NOT present (e.g. maybe Emacs 24.1). Let's say this is revision 1000.
bzr bisect start
bzr bisect no -r 1000
At this point, bzr will switch to the mid-point of revision 1000 and
the current revision. If you know that the issue was definitely
present in some specific revision (say 2000), you can use:
bzr bisect yes -r 2000
Now bzr switches to revision 1500.
Now test whether the issue is present. You might need to rebuild
Emacs to do this, or if you know the problem is in a specific Lisp
file, you might be able to get away with just loading that one file in
current Emacs.
If the issue is present, use
bzr bisect yes
If it is not, use
bzr bisect no
Repeat until you zero-in on the specific revision.
When finished, use
bzr bisect reset
or simply delete the entire branch if you created it just for this.
* Commit emails
** Old method: bzr-hookless-email
https://launchpad.net/bzr-hookless-email
Runs hourly via cron. Must ask Savannah admins to enable/disable it
for each branch. Stores the last revision that it mailed as
last_revision_mailed in branch.conf on the server. Breaks with bzr 2.6:
http://lists.gnu.org/archive/html/savannah-hackers-public/2013-05/msg00000.html
Fix from https://bugs.launchpad.net/bzr-hookless-email/+bug/988195
only partially works. Breaks again on every merge commit:
https://lists.ubuntu.com/archives/bazaar/2013q2/075520.html
http://lists.gnu.org/archive/html/savannah-hackers-public/2013-05/msg00024.html
You can force it to skip the merge commit by changing the value for
last_revision_mailed, eg:
bzr config last_revision_mailed=xfq.free@gmail.com-20130603233720-u1aumaxvf3o0rlai -d bzr+ssh://USERNAME@bzr.savannah.gnu.org/emacs/trunk/
** New method: bzr-email plugin
https://launchpad.net/bzr-email
http://lists.gnu.org/archive/html/savannah-hackers-public/2013-06/msg00007.html
Runs on commit. Projects can enable it themselves by using `bzr
config' to set post_commit_to option for a branch. See `bzr help email'
(if you have the plugin installed) for other options.
The From: address will be that of your Savannah account, rather than
your `bzr whoami' information.
Note: if you have the bzr-email plugin installed locally, then when
you commit to the Emacs repository it will also try to send a commit
email from your local machine. If your machine is not configured to
send external mail, this will just fail. In any case, you may prefer
to either remove the plugin from your machine, or disable it for Emacs
branches. You can do this either by editing branch.conf in your Emacs
branches, to override the server setting (untested; not sure this
works), or by adding an entry to ~/.bazaar/locations.conf:
[bzr+ssh://USERNAME@bzr.savannah.gnu.org/emacs/*/]
post_commit_to = ""
You have to use locations.conf rather than bazaar.conf because the
latter has a lower priority than branch.conf.
* Using git-bzr
** initially
You can use Git locally to talk to the Bazaar repo as a "remote" repo
via git-bzr (aka git-remote-bzr). Initial clone:
git clone bzr::bzr+ssh://USER@bzr.sv.gnu.org/emacs/trunk e
This creates the working dir e/ (with subdir .git, etc). Disk usage
is 13G (as of early 2014), so you will probably want to repack:
git repack -a -d -f --window=250 --depth=250 --window-memory=N
where N is chosen to avoid swapping. E.g., given 512MB RAM, N="200m"
results in "du -sh .git" => 559M, about double the smallest reported
value (obtained with "deprecated" command "git gc --aggressive").
** steady-state
Use "fetch", "pull" and other remote-to-local commands as usual.
For "push", the Emacs Bazaar repo is configured with
append_revisions_only = True
so some versions of git-remote-bzr may raise AppendRevisionsOnlyViolation
(in func do_export) instead of displaying a "non fast-forward" message
and skipping the branch. See:
http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00436.html
which includes a provisional patch to git-remote-bzr to do that.

1989
admin/notes/tags
View file

File diff suppressed because it is too large Load diff

3
admin/update-copyright
View file

@ -45,8 +45,7 @@ sed 's/\\def\\year[{][0-9]*[}]/\\def\\year{'"$UPDATE_COPYRIGHT_YEAR"'}'/g \
} &&
rm $emacsver.aux &&
# FIXME: command will soon need to be replaced with "git ls-files"
repo_files=$(bzr ls -RV --kind file) &&
repo_files=$(git ls-files) &&
# Do not update the copyright of files that have one or more of the
# following problems:

6
etc/CONTRIBUTE
View file

@ -120,9 +120,9 @@ Manual, for how to write good log entries.
** The patch itself.
If you are accessing the Bazaar repository, make sure your copy is
up-to-date (e.g. with `bzr pull'), then use
bzr diff --no-aliases --diff-options=-cp
If you are accessing the Emacs repository, make sure your copy is
up-to-date (e.g. with `git pull'), then use
git diff
Else, use
diff -cp OLD NEW

4
etc/ChangeLog
View file

@ -1,3 +1,7 @@
2014-11-11 Eric S. Raymond <esr@thyrsus.com>
* CONTRIBUTE: git transition.
2014-10-20 Glenn Morris <rgm@gnu.org>
* Version 24.4 released.