NAME
----
-git-svn - bidirectional operation between a single Subversion branch and git
+git-svn - bidirectional operation between Subversion and git
SYNOPSIS
--------
DESCRIPTION
-----------
-git-svn is a simple conduit for changesets between a single Subversion
-branch and git. It is not to be confused with gitlink:git-svnimport[1].
-They were designed with very different goals in mind.
+git-svn is a simple conduit for changesets between Subversion and git.
+It is not to be confused with gitlink:git-svnimport[1], which is
+read-only and geared towards tracking multiple branches.
-git-svn is designed for an individual developer who wants a
+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. git-svnimport is designed
-for read-only operation on repositories that match a particular layout
-(albeit the recommended one by SVN developers).
+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; but it cannot (yet) automatically detect new
+branches and tags like git-svnimport does.
-For importing svn, git-svnimport is potentially more powerful when
-operating on repositories organized under the recommended
-trunk/branch/tags structure, and should be faster, too.
-
-git-svn mostly ignores the very limited view of branching that
-Subversion has. This allows git-svn to be much easier to use,
-especially on repositories that are not organized in a manner that
-git-svnimport is designed for.
+git-svn is especially useful when it comes to tracking repositories
+not organized in the way Subversion developers recommend (trunk,
+branches, tags directories).
COMMANDS
--------
manually joining branches on commit.
'dcommit'::
- Commit all diffs from a specified head directly to the SVN
+ Commit each diff from a specified head directly to the SVN
repository, and then rebase or reset (depending on whether or
- not there is a diff between SVN and head). It is recommended
- that you run git-svn fetch and rebase (not pull) your commits
- against the latest changes in the SVN repository.
+ not there is a diff between SVN and head). This will create
+ a revision in SVN for each commit in git.
+ It is recommended that you run git-svn fetch and rebase (not
+ pull or merge) your commits against the latest changes in the
+ SVN repository.
An optional command-line argument may be specified as an
alternative to HEAD.
- This is advantageous over 'commit' (below) because it produces
+ This is advantageous over 'set-tree' (below) because it produces
cleaner, more linear history.
'log'::
Any other arguments are passed directly to `git log'
-'commit'::
+'set-tree'::
You should consider using 'dcommit' instead of this command.
Commit specified commit or tree objects to SVN. This relies on
your imported fetch data being up-to-date. This makes
-::
--stdin::
-Only used with the 'commit' command.
+Only used with the 'set-tree' command.
Read a list of commits from stdin and commit them in reverse
order. Only the leading sha1 is read from each line, so
--rmdir::
-Only used with the 'dcommit', 'commit' and 'commit-diff' commands.
+Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands.
Remove directories from the SVN tree if there are no files left
behind. SVN can version empty directories, and they are not
-e::
--edit::
-Only used with the 'dcommit', 'commit' and 'commit-diff' commands.
+Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands.
Edit the commit message before committing to SVN. This is off by
default for objects that are commits, and forced on when committing
-l<num>::
--find-copies-harder::
-Only used with the 'dcommit', 'commit' and 'commit-diff' commands.
+Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands.
They are both passed directly to git-diff-tree see
gitlink:git-diff-tree[1] for more information.
-b<refname>::
--branch <refname>::
-Used with 'fetch', 'dcommit' or 'commit'.
+Used with 'fetch', 'dcommit' or 'set-tree'.
This can be used to join arbitrary git branches to remotes/git-svn
on new commits where the tree object is equivalent.
Basic Examples
~~~~~~~~~~~~~~
-Tracking and contributing to a Subversion-managed project:
+Tracking and contributing to a the trunk of a Subversion-managed project:
------------------------------------------------------------------------
# Initialize a repo (like git init-db):
git-svn show-ignore >> .git/info/exclude
------------------------------------------------------------------------
-REBASE VS. PULL
----------------
+Tracking and contributing to an entire Subversion-managed project
+(complete with a trunk, tags and branches):
+See also:
+'<<tracking-multiple-repos,Tracking Multiple Repositories or Branches>>'
+
+------------------------------------------------------------------------
+# Initialize a repo (like git init-db):
+ git-svn multi-init http://svn.foo.org/project \
+ -T trunk -b branches -t tags
+# Fetch remote revisions:
+ git-svn multi-fetch
+# Create your own branch of trunk to hack on:
+ git checkout -b my-trunk remotes/trunk
+# Do some work, and then commit your new changes to SVN, as well as
+# automatically updating your working HEAD:
+ git-svn dcommit -i trunk
+# Something has been committed to trunk, rebase the latest into your branch:
+ git-svn multi-fetch && git rebase remotes/trunk
+# Append svn:ignore settings of trunk to the default git exclude file:
+ git-svn show-ignore -i trunk >> .git/info/exclude
+# Check for new branches and tags (no arguments are needed):
+ git-svn multi-init
+------------------------------------------------------------------------
+
+REBASE VS. PULL/MERGE
+---------------------
Originally, git-svn recommended that the remotes/git-svn branch be
-pulled from. This is because the author favored 'git-svn commit B'
-to commit a single head rather than the 'git-svn commit A..B' notation
-to commit multiple commits.
-
-If you use 'git-svn commit A..B' to commit several diffs and you do not
-have the latest remotes/git-svn merged into my-branch, you should use
-'git rebase' to update your work branch instead of 'git pull'. 'pull'
-can cause non-linear history to be flattened when committing into SVN,
-which can lead to merge commits reversing previous commits in SVN.
+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.
+
+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 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.
DESIGN PHILOSOPHY
-----------------