Merge branch 'maint'

[git.git] / Documentation / git-svn.txt

diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 3e2a63b7460f4051fae52b7c1b2ceb4ea6dd1163..488e4b1caf8097de4ab53bf89a03f80173a2cf52 100644 (file)
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -99,7 +99,7 @@ COMMANDS
 
 This works similarly to 'svn update' or 'git-pull' except that
 it preserves linear history with 'git-rebase' instead of
-'git-merge' for ease of dcommit-ing with git-svn.
+'git-merge' for ease of dcommiting with git-svn.
 
 This accepts all options that 'git-svn fetch' and 'git-rebase'
 accepts.  However '--fetch-all' only fetches from the current
@@ -404,7 +404,7 @@ section because they affect the 'git-svn-id:' metadata line.
 BASIC EXAMPLES
 --------------
 
-Tracking and contributing to a the trunk of a Subversion-managed project:
+Tracking and contributing to the trunk of a Subversion-managed project:
 
 ------------------------------------------------------------------------
 # Clone a repo (like git clone):
@@ -478,11 +478,12 @@ previous commits in SVN.
 DESIGN PHILOSOPHY
 -----------------
 Merge tracking in Subversion is lacking and doing branched development
-with Subversion is cumbersome as a result.  git-svn does not do
-automated merge/branch tracking by default and leaves it entirely up to
-the user on the git side.  git-svn does however follow copy
-history of the directory that it is tracking, however (much like
-how 'svn log' works).
+with Subversion can be cumbersome as a result.  While git-svn can track
+copy history (including branches and tags) for repositories adopting a
+standard layout, it cannot yet represent merge history that happened
+inside git back upstream to SVN users.  Therefore it is advised that
+users keep history as linear as possible inside git to ease
+compatibility with SVN (see the CAVEATS section below).
 
 CAVEATS
 -------
@@ -549,9 +550,9 @@ listed below are allowed:
 ------------------------------------------------------------------------
 
 Keep in mind that the '*' (asterisk) wildcard of the local ref
-(left of the ':') *must* be the farthest right path component;
+(right of the ':') *must* be the farthest right path component;
 however the remote wildcard may be anywhere as long as it's own
-independent path componet (surrounded by '/' or EOL).   This
+independent path component (surrounded by '/' or EOL).   This
 type of configuration is not automatically created by 'init' and
 should be manually entered with a text-editor or using
 gitlink:git-config[1]