apply --whitespace=warn/error: diagnose blank at EOF
[gitweb.git] / Documentation / git-svn.txt
index f230125a81baab9f13bf84e3543b63fc77a8e827..b6577dd4c480291fb6e51c6c1cfc92d0f4dc8796 100644 (file)
@@ -13,7 +13,7 @@ DESCRIPTION
 -----------
 'git-svn' is a simple conduit for changesets between Subversion and git.
 It provides a bidirectional flow of changes between a Subversion and a git
-respository.
+repository.
 
 'git-svn' can track a single Subversion branch simply by using a
 URL to the branch, follow branches laid out in the Subversion recommended
@@ -109,7 +109,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 dcommiting with 'git-svn'.
+'git-merge' for ease of dcommitting with 'git-svn'.
 
 This accepts all options that 'git-svn fetch' and 'git-rebase'
 accept.  However, '--fetch-all' only fetches from the current
@@ -138,6 +138,15 @@ and have no uncommitted changes.
 +
 --no-rebase;;
        After committing, do not rebase or reset.
+--commit-url <URL>;;
+       Commit to this SVN URL (the full path).  This is intended to
+       allow existing git-svn repositories created with one transport
+       method (e.g. `svn://` or `http://` for anonymous read) to be
+       reused if a user is later given access to an alternate transport
+       method (e.g. `svn+ssh://` or `https://`) for commit.
+
+       Using this option for any other purpose (don't ask)
+       is very strongly discouraged.
 --
 
 'log'::
@@ -209,7 +218,7 @@ Any other arguments are passed directly to 'git-log'
        Recursively finds the svn:ignore property on directories and
        creates matching .gitignore files. The resulting files are staged to
        be committed, but are not committed. Use -r/--revision to refer to a
-       specfic revision.
+       specific revision.
 
 'show-ignore'::
        Recursively finds and lists the svn:ignore property on
@@ -464,7 +473,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.example.com/project/trunk
 # Enter the newly cloned directory:
        cd trunk
 # You should be on master branch, double-check with git-branch
@@ -486,7 +495,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.example.com/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'
@@ -505,7 +514,7 @@ 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.example.com/project
 # Clone locally - make sure the refs/remotes/ space matches the server
        mkdir project
        cd project
@@ -513,8 +522,10 @@ have each person clone that repository with 'git-clone':
        git remote add origin server:/pub/project
        git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
        git fetch
+# Create a local branch from one of the branches just fetched
+       git checkout -b master FETCH_HEAD
 # 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.example.com/project
 # Pull the latest changes from Subversion
        git svn rebase
 ------------------------------------------------------------------------
@@ -530,7 +541,7 @@ pulled or merged from.  This is because the author favored
 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
-`git merge`.  `pull`/`merge' can cause non-linear history to be flattened
+`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.