[PATCH 1/2] Documentation/git-svn.txt: Remove the hyphen from git-foo when quoted

[PATCH 1/2] Documentation/git-svn.txt: Remove the hyphen from git-foo when quoted

[Peter Harris]

The git-foo forms are deprecated in favour of "git foo"

Signed-off-by: Peter <git@peter.is-a-geek.org>
---
 Documentation/git-svn.txt |   50 ++++++++++++++++++++++----------------------
 1 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index b1d527f..f94d0f9 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -97,20 +97,20 @@ COMMANDS
 	This fetches revisions from the SVN parent of the current HEAD
 	and rebases the current (uncommitted to SVN) work against it.
 
-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 dcommiting with git-svn.
+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 dcommiting with git-svn.
 
-This accepts all options that 'git-svn fetch' and 'git-rebase'
+This accepts all options that 'git svn fetch' and 'git rebase'
 accepts.  However '--fetch-all' only fetches from the current
 [svn-remote], and not all [svn-remote] definitions.
 
-Like 'git-rebase'; this requires that the working tree be clean
+Like 'git rebase'; this requires that the working tree be clean
 and have no uncommitted changes.
 
 -l;;
 --local;;
-	Do not fetch remotely; only run 'git-rebase' against the
+	Do not fetch remotely; only run 'git rebase' against the
 	last fetched commit from the upstream SVN.
 
 'dcommit'::
@@ -313,7 +313,7 @@ config key: svn.repackflags
 These are only used with the 'dcommit' and 'rebase' commands.
 
 Passed directly to git-rebase when using 'dcommit' if a
-'git-reset' cannot be used (see dcommit).
+'git reset' cannot be used (see dcommit).
 
 -n::
 --dry-run::
@@ -366,7 +366,7 @@ If you lose your .git/svn/git-svn/.rev_db file, git-svn will not
 be able to rebuild it and you won't be able to fetch again,
 either.  This is fine for one-shot imports.
 
-The 'git-svn log' command will not work on repositories using
+The 'git svn log' command will not work on repositories using
 this, either.  Using this conflicts with the 'useSvmProps'
 option for (hopefully) obvious reasons.
 
@@ -414,7 +414,7 @@ Tracking and contributing to the trunk of a Subversion-managed project:
 
 ------------------------------------------------------------------------
 # Clone a repo (like git clone):
-	git-svn clone http://svn.foo.org/project/trunk
+	git svn clone http://svn.foo.org/project/trunk
 # Enter the newly cloned directory:
 	cd trunk
 # You should be on master branch, double-check with git-branch
@@ -423,12 +423,12 @@ Tracking and contributing to the trunk of a Subversion-managed project:
 	git commit ...
 # Something is committed to SVN, rebase your local changes against the
 # latest changes in SVN:
-	git-svn rebase
+	git svn rebase
 # Now commit your changes (that were committed previously using git) to SVN,
 # as well as automatically updating your working HEAD:
-	git-svn dcommit
+	git svn dcommit
 # Append svn:ignore settings to the default git exclude file:
-	git-svn show-ignore >> .git/info/exclude
+	git svn show-ignore >> .git/info/exclude
 ------------------------------------------------------------------------
 
 Tracking and contributing to an entire Subversion-managed project
@@ -436,7 +436,7 @@ Tracking and contributing to an entire Subversion-managed project
 
 ------------------------------------------------------------------------
 # Clone a repo (like git clone):
-	git-svn clone http://svn.foo.org/project -T trunk -b branches -t tags
+	git svn clone http://svn.foo.org/project -T trunk -b branches -t tags
 # View all branches and tags you have cloned:
 	git branch -r
 # Reset your master to trunk (or any other branch, replacing 'trunk'
@@ -446,27 +446,27 @@ Tracking and contributing to an entire Subversion-managed project
 # of dcommit/rebase/show-ignore should be the same as above.
 ------------------------------------------------------------------------
 
-The initial 'git-svn clone' can be quite time-consuming
+The initial 'git svn clone' can be quite time-consuming
 (especially for large Subversion repositories). If multiple
 people (or one person with multiple machines) want to use
 git-svn to interact with the same Subversion repository, you can
-do the initial 'git-svn clone' to a repository on a server and
+do the initial 'git svn clone' to a repository on a server and
 have each person clone that repository with 'git clone':
 
 ------------------------------------------------------------------------
 # Do the initial import on a server
-	ssh server "cd /pub && git-svn clone http://svn.foo.org/project
+	ssh server "cd /pub && git svn clone http://svn.foo.org/project
 # Clone locally - make sure the refs/remotes/ space matches the server
 	mkdir project
 	cd project
-	git-init
+	git init
 	git remote add origin server:/pub/project
 	git config --add remote.origin.fetch=+refs/remotes/*:refs/remotes/*
 	git fetch
 # Initialize git-svn locally (be sure to use the same URL and -T/-b/-t options as were used on server)
-	git-svn init http://svn.foo.org/project
+	git svn init http://svn.foo.org/project
 # Pull the latest changes from Subversion
-	git-svn rebase
+	git svn rebase
 ------------------------------------------------------------------------
 
 REBASE VS. PULL/MERGE
@@ -474,12 +474,12 @@ REBASE VS. PULL/MERGE
 
 Originally, git-svn recommended that the remotes/git-svn branch be
 pulled or merged from.  This is because the author favored
-'git-svn set-tree B' to commit a single head rather than the
-'git-svn set-tree A..B' notation to commit multiple commits.
+'git svn set-tree B' to commit a single head rather than the
+'git svn set-tree A..B' notation to commit multiple commits.
 
-If you use 'git-svn set-tree A..B' to commit several diffs and you do
+If you use 'git svn set-tree A..B' to commit several diffs and you do
 not have the latest remotes/git-svn merged into my-branch, you should
-use 'git-svn rebase' to update your work branch instead of 'git pull' or
+use 'git svn rebase' to update your work branch instead of 'git pull' or
 'git merge'.  'pull/merge' can cause non-linear history to be flattened
 when committing into SVN, which can lead to merge commits reversing
 previous commits in SVN.
@@ -504,14 +504,14 @@ operations between git repositories and branches.  The recommended
 method of exchanging code between git branches and users is
 git-format-patch and git-am, or just dcommiting to the SVN repository.
 
-Running 'git-merge' or 'git-pull' is NOT recommended on a branch you
+Running 'git merge' or 'git pull' is NOT recommended on a branch you
 plan to dcommit from.  Subversion does not represent merges in any
 reasonable or useful fashion; so users using Subversion cannot see any
 merges you've made.  Furthermore, if you merge or pull from a git branch
 that is a mirror of an SVN branch, dcommit may commit to the wrong
 branch.
 
-'git-clone' does not clone branches under the refs/remotes/ hierarchy or
+'git clone' does not clone branches under the refs/remotes/ hierarchy or
 any git-svn metadata, or config.  So repositories created and managed with
 using git-svn should use rsync(1) for cloning, if cloning is to be done
 at all.
-- 
1.5.3.7