DESCRIPTION
-----------
'git-svn' is a simple conduit for changesets between Subversion and git.
-It is not to be confused with linkgit:git-svnimport[1], which is
-read-only.
+It provides a bidirectional flow of changes between a Subversion and a git
+repository.
-'git-svn' was originally designed for an individual developer who wants a
-bidirectional flow of changesets between a single branch in Subversion
-and an arbitrary number of branches in git. Since its inception,
-'git-svn' has gained the ability to track multiple branches in a manner
-similar to 'git-svnimport'.
+'git-svn' can track a single Subversion branch simply by using a
+URL to the branch, follow branches laid out in the Subversion recommended
+method (trunk, branches, tags directories) with the --stdlayout option, or
+follow branches in any layout with the -T/-t/-b options (see options to
+'init' below, and also the 'clone' command).
-'git-svn' is especially useful when it comes to tracking repositories
-not organized in the way Subversion developers recommend (trunk,
-branches, tags directories).
+Once tracking a Subversion branch (with any of the above methods), the git
+repository can be updated from Subversion by the 'fetch' command and
+Subversion updated from git by the 'dcommit' command.
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
+
--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'::
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
'commit-diff'::
Commits the diff of two tree-ish arguments from the
- command-line. This command is intended for interoperability with
- 'git-svnimport' and does not rely on being inside an `git-svn
+ command-line. This command does not rely on being inside an `git-svn
init`-ed repository. This command takes three arguments, (a) the
original tree to diff against, (b) the new tree result, (c) the
URL of the target Subversion repository. The final argument
-A<filename>::
--authors-file=<filename>::
-Syntax is compatible with the files used by 'git-svnimport' and
-'git-cvsimport':
+Syntax is compatible with the file used by 'git-cvsimport':
------------------------------------------------------------------------
loginname = Joe User <user@example.com>
------------------------------------------------------------------------
# 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
------------------------------------------------------------------------
# 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'
------------------------------------------------------------------------
# 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
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
------------------------------------------------------------------------
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.
For the sake of simplicity and interoperating with a less-capable system
(SVN), it is recommended that all 'git-svn' users clone, fetch and dcommit
-directly from the SVN server, and avoid all 'git-clone'/`pull`/`merge`/`push`
+directly from the SVN server, and avoid all 'git-clone'/'pull'/'merge'/'push'
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 'dcommit'ing to the SVN repository.