Replace old CVS references with GIT

HACKING

@@ -15,14 +15,14 @@ should work:
 
 or:
 
-  cvs diff -up > libvirt-myfeature.patch
+  git diff > libvirt-myfeature.patch
 
 (3) Split large changes into a series of smaller patches, self-contained
 if possible, with an explanation of each patch and an explanation of how
 the sequence of patches fits together.
 
-(4) Make sure your patches apply against libvirt CVS.  Developers
-only follow CVS and don't care much about released versions.
+(4) Make sure your patches apply against libvirt GIT.  Developers
+only follow GIT and don't care much about released versions.
 
 (5) Run the automated tests on your code before submitting any changes.
 In particular, configure with compile warnings set to -Werror:

docs/FAQ.html.in

@@ -119,7 +119,7 @@
     packages as well as the public headers to compile against libxenstore.</p>
       </li>
       <li>
-        <em>I use the CVS version and there is no configure script</em>
+        <em>I use the GIT version and there is no configure script</em>
         <p>The configure script (and other Makefiles) are generated. Use the
     autogen.sh script to regenerate the configure script and Makefiles,
     like:</p>

docs/bugs.html.in

@@ -16,7 +16,7 @@
     <p>
       If you are using official libvirt binaries from a Linux distribution
       check below for distribution specific bug reporting policies first.
-      For general libvirt bug reports, from self-built releases, CVS snapshots
+      For general libvirt bug reports, from self-built releases, GIT snapshots
       and any other non-distribution supported builds, enter tickets under
       the <code>Virtualization Tools</code> product and the <code>libvirt</code>
       component.
@@ -64,8 +64,8 @@
     </p>
 
     <ul>
-      <li>The version number of the libvirt build, or date of the CVS
-        checkout</li>
+      <li>The version number of the libvirt build, or SHA1 of the GIT
+        commit</li>
       <li>The hardware architecture being used</li>
       <li>The name of the hypervisor (Xen, QEMU, KVM)</li>
       <li>The XML config of the guest domain if relevant</li>

docs/contact.html.in

@@ -12,8 +12,8 @@
       <a href="https://www.redhat.com/mailman/listinfo/libvir-list">associated Web</a>
       page and follow the instructions. Patches with explanations and provided as
       attachments are really appreciated and will be discussed on the mailing list.
-      If possible generate the patches by using <code>cvs diff -up</code> in a CVS
-      checkout.
+      If possible generate the patches by using <code>git diff</code> in a GIT
+      clone.
     </p>
 
     <h2>IRC discussion</h2>

docs/deployment.html.in

@@ -25,10 +25,10 @@
       # make install
     </pre>
 
-    <h2>Built from CVS / GIT</h2>
+    <h2>Built from GIT</h2>
 
     <p>
-      When building from CVS it is necessary to generate the autotools
+      When building from GIT it is necessary to generate the autotools
       support files. This requires having <code>autoconf</code>,
       <code>automake</code>, <code>libtool</code> and <code>intltool</code>
       installed. The process can be automated with the <code>autogen.sh</code>

docs/hacking.html.in

@@ -19,13 +19,13 @@
           or:
         </p>
         <pre>
-  cvs diff -up > libvirt-myfeature.patch
+  git diff > libvirt-myfeature.patch
 </pre></li>
       <li>Split large changes into a series of smaller patches, self-contained
         if possible, with an explanation of each patch and an explanation of how
         the sequence of patches fits together.</li>
-      <li>Make sure your patches apply against libvirt CVS.  Developers
-        only follow CVS and don't care much about released versions.</li>
+      <li>Make sure your patches apply against libvirt GIT.  Developers
+        only follow GIT and don't care much about released versions.</li>
       <li><p>Run the automated tests on your code before submitting any changes.
           In particular, configure with compile warnings set to -Werror:</p>
         <pre>

src/Makefile.am

@@ -367,7 +367,7 @@ if HAVE_RPCGEN
 # Maintainer-only target for re-generating the derived .c/.h source
 # files, which are actually derived from the .x file.
 #
-# For committing protocol changes to CVS, the GLIBC rpcgen *must*
+# For committing protocol changes to GIT, the GLIBC rpcgen *must*
 # be used.
 #
 # Support for non-GLIB rpcgen is here as a convenience for