Backport changes in preparation for git migration from trunk.

 admin: Changes in several documents.
 autogen.sh: Neutralize language specific to a repository type.

 doc/misc/efaq-w32.texi: Neutralized language specific to a repository type.

 doc/misc/gnus-coding.txt: Neutralized language specific to a repository type.

 lisp/Makefile.in: Change some production names so they're neutral
 about the repository type.

7 files changed, 48 insertions, 43 deletions

diff --git a/admin/check-doc-strings b/admin/check-doc-strings
index a0b5acb623f..13e8b0cd8e7 100755
--- a/admin/check-doc-strings
+++ b/admin/check-doc-strings
@@ -18,7 +18,7 @@ formal parameters, docstrings, and lispref texi.
 This program is in the public domain.\n";
 
 die $usage if @ARGV;
-die $usage unless -r "src/alloc.c" && -d ".bzr" && -d "lisp";
+die $usage unless -r "src/alloc.c" && -d "lisp";
 
 my %texi_funtype;
 my %texi_arglist;
diff --git a/admin/notes/BRANCH b/admin/notes/BRANCH
deleted file mode 100644
index 9f09135f206..00000000000
--- a/admin/notes/BRANCH
+++ /dev/null
@@ -1,32 +0,0 @@
-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.
-
-Development is discussed on the emacs-devel mailing list.
-
-Sometime before the release of a new major version of Emacs (eg 23.2),
-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.
-
-If you are looking at this file in a branch other than the trunk,
-there may be some branch-specific documentation below this line.
-________________________________________________________________________
-
-* 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.
diff --git a/admin/notes/copyright b/admin/notes/copyright
index a54bcb6108b..74aa73b0394 100644
--- a/admin/notes/copyright
+++ b/admin/notes/copyright
@@ -24,7 +24,7 @@ the file.
 
 2. When installing code written by someone else, the ChangeLog entry
 should be in the name of the author of the code, not the person who
-installs it.  Also use bzr commit's "--author" option.
+installs it.  Also use commit's "--author" option.
 Do not install any of your own changes in the same commit.
 
 3. With images, add the legal info to a README file in the directory
@@ -493,10 +493,10 @@ system)
     obviously good):
 
 
-Is it OK to just `bzr remove' a file for legal reasons, or is
-something more drastic needed? A removed file is still available from
-the repository, if suitable options are applied. (This issue obviously
-does not affect a release).
+Is it OK to just remove a file for legal reasons, or is something more
+drastic (excision from the entire repository history) needed? A
+removed file is still available from the repository, if suitable
+options are applied. (This issue obviously does not affect a release).
   rms: will ask lawyer
 
 
diff --git a/admin/notes/hydra b/admin/notes/hydra
index 3b6bc87a2f6..ce2047480d2 100644
--- a/admin/notes/hydra
+++ b/admin/notes/hydra
@@ -26,7 +26,7 @@ http://lists.gnu.org/mailman/listinfo/emacs-buildstatus
 * The Emacs jobset consists of the following jobs:
 
 ** The `tarball' job
-which gets a checkout from bzr, and does a bootstrap followed
+which gets a checkout from the repository, and does a bootstrap followed
 by running make-dist to create a tarball.  If this job fails, all the
 others will too (because they use the tarball as input).
 
diff --git a/admin/notes/bzr b/admin/notes/repo
index a1ef8f64133..c398d3a4ae2 100644
--- a/admin/notes/bzr
+++ b/admin/notes/repo
@@ -1,6 +1,39 @@
-NOTES ON COMMITTING TO EMACS'S BAZAAR REPO    -*- outline -*-
+NOTES ON COMMITTING TO EMACS'S REPOSITORY    -*- outline -*-
+
+* 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.
+
+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
@@ -19,6 +52,7 @@ and branch yourself (when committing the branch change, indicate
 in the commit log that it should not be merged to the trunk; see below).
 
 * 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
@@ -27,6 +61,7 @@ person merging the release branch to the trunk.
 http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00262.html
 
 * 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
@@ -47,6 +82,7 @@ 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
diff --git a/admin/notes/years b/admin/notes/years
index 342fe9e2307..c0db1854e30 100644
--- a/admin/notes/years
+++ b/admin/notes/years
@@ -2,7 +2,7 @@ HOW TO MAINTAIN COPYRIGHT YEARS FOR GNU EMACS
 
 Maintaining copyright years is now very simple: every time a new year
 rolls around, add that year to every FSF (and AIST) copyright notice.
-Do this by running the 'admin/update-copyright' script on a fresh bzr
+Do this by running the 'admin/update-copyright' script on a fresh repo
 checkout.  Inspect the results for plausibility, then commit them.
 
 There's no need to worry about whether an individual file has changed
diff --git a/admin/update-copyright b/admin/update-copyright
index 2b33506f9c1..ce58168684e 100755
--- a/admin/update-copyright
+++ b/admin/update-copyright
@@ -45,14 +45,15 @@ sed 's/\\def\\year[{][0-9]*[}]/\\def\\year{'"$UPDATE_COPYRIGHT_YEAR"'}'/g \
 } &&
 rm $emacsver.aux &&
 
-bzr_files=$(bzr ls -RV --kind file) &&
+# FIXME: command will soon need to be replaced with "git ls-files"
+repo_files=$(bzr ls -RV --kind file) &&
 
 # Do not update the copyright of files that have one or more of the
 # following problems:
 # . They are license files, maintained by the FSF, with their own dates.
 # . Their format cannot withstand changing the contents of copyright strings.
 
-updatable_files=$(find $bzr_files \
+updatable_files=$(find $repo_files \
   ! -name COPYING \
   ! -name doclicense.texi \
   ! -name gpl.texi \