git-svn: handle our top-level path being deleted and later re-added

diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index 4ea9e85d5e7c9b9082c4892548ab798d23f30e6d..0cc6511bdf35f29ce946726485f71eeddddce56b 100644 (file)
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -8,6 +8,7 @@ git-bundle - Move objects and refs by archive
 
 SYNOPSIS
 --------
+[verse]
 'git-bundle' create <file> [git-rev-list args]
 'git-bundle' verify <file>
 'git-bundle' list-heads <file> [refname...]
@@ -19,7 +20,7 @@ DESCRIPTION
 Some workflows require that one or more branches of development on one
 machine be replicated on another machine, but the two machines cannot
 be directly connected so the interactive git protocols (git, ssh,
-rsync, http) cannot be used.  This command provides suport for
+rsync, http) cannot be used.  This command provides support for
 git-fetch and git-pull to operate by packaging objects and references
 in an archive at the originating machine, then importing those into
 another repository using gitlink:git-fetch[1] and gitlink:git-pull[1]
@@ -58,7 +59,7 @@ unbundle <file>::
        gitlink:git-fetch[1].
 
 [git-rev-list-args...]::
-       A list of arguments, accepatble to git-rev-parse and
+       A list of arguments, acceptable to git-rev-parse and
        git-rev-list, that specify the specific objects and references
        to transport.  For example, "master~10..master" causes the
        current master reference to be packaged along with all objects
@@ -70,7 +71,7 @@ unbundle <file>::
 [refname...]::
        A list of references used to limit the references reported as
        available. This is principally of use to git-fetch, which
-       expects to recieve only those references asked for and not
+       expects to receive only those references asked for and not
        necessarily everything in the pack (in this case, git-bundle is
        acting like gitlink:git-fetch-pack[1]).
 
@@ -87,7 +88,7 @@ specified explicitly (e.g., ^master~10), or implicitly (e.g.,
 master~10..master, master --since=10.days.ago).
 
 It is very important that the basis used be held by the destination.
-It is ok to err on the side of conservatism, causing the bundle file
+It is okay to err on the side of conservatism, causing the bundle file
 to contain objects already in the destination as these are ignored
 when unpacking at the destination.
 
@@ -102,14 +103,20 @@ We set a tag in R1 (lastR2bundle) after the previous such transport,
 and move it afterwards to help build the bundle.
 
 in R1 on A:
+
+------------
 $ git-bundle create mybundle master ^lastR2bundle
 $ git tag -f lastR2bundle master
+------------
 
 (move mybundle from A to B by some mechanism)
 
 in R2 on B:
+
+------------
 $ git-bundle verify mybundle
 $ git-fetch mybundle  refspec
+------------
 
 where refspec is refInBundle:localRef
 
@@ -123,9 +130,11 @@ Also, with something like this in your config:
 You can first sneakernet the bundle file to ~/tmp/file.bdl and
 then these commands:
 
+------------
 $ git ls-remote bundle
 $ git fetch bundle
 $ git pull bundle
+------------
 
 would treat it as if it is talking with a remote side over the
 network.