</p>\r
<p>Note: You should never attempt to modify the remotes/git-svn\r
branch outside of git-svn. Instead, create a branch from\r
-remotes/git-svn and work on that branch. Use the <em>commit</em>\r
+remotes/git-svn and work on that branch. Use the <em>dcommit</em>\r
command (see below) to write git commits back to\r
remotes/git-svn.</p>\r
<p>See <em><a href="#fetch-args">Additional Fetch Arguments</a></em> if you are interested in\r
</dt>\r
<dd>\r
<p>\r
-Used with <em>fetch</em> or <em>commit</em>.\r
+Used with <em>fetch</em>, <em>dcommit</em> or <em>commit</em>.\r
</p>\r
<p>This can be used to join arbitrary git branches to remotes/git-svn\r
on new commits where the tree object is equivalent.</p>\r
</dd>\r
</dl>\r
<h3>Basic Examples</h3>\r
-<p>Tracking and contributing to an Subversion managed-project:</p>\r
+<p>Tracking and contributing to a Subversion-managed project:</p>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt># Initialize a repo (like git init-db):\r
git-svn fetch\r
# Create your own branch to hack on:\r
git checkout -b my-branch remotes/git-svn\r
-# Commit only the git commits you want to SVN:\r
- git-svn commit <tree-ish> [<tree-ish_2> ...]\r
-# Commit all the git commits from my-branch that don't exist in SVN:\r
- git-svn commit remotes/git-svn..my-branch\r
+# Do some work, and then commit your new changes to SVN, as well as\r
+# automatically updating your working HEAD:\r
+ git-svn dcommit\r
# Something is committed to SVN, rebase the latest into your branch:\r
git-svn fetch && git rebase remotes/git-svn\r
# Append svn:ignore settings to the default git exclude file:\r
<h2>DESIGN PHILOSOPHY</h2>\r
<div class="sectionbody">\r
<p>Merge tracking in Subversion is lacking and doing branched development\r
-with Subversion is cumbersome as a result. git-svn completely forgoes\r
-any automated merge/branch tracking on the Subversion side and leaves it\r
-entirely up to the user on the git side. It's simply not worth it to do\r
-a useful translation when the original signal is weak.</p>\r
+with Subversion is cumbersome as a result. git-svn does not do\r
+automated merge/branch tracking by default and leaves it entirely up to\r
+the user on the git side.</p>\r
</div>\r
<h2><a id="tracking-multiple-repos"></a>TRACKING MULTIPLE REPOSITORIES OR BRANCHES</h2>\r
<div class="sectionbody">\r
-<p>This is for advanced users, most users should ignore this section.</p>\r
<p>Because git-svn does not care about relationships between different\r
branches or directories in a Subversion repository, git-svn has a simple\r
hack to allow it to track an arbitrary number of related _or_ unrelated\r
-SVN repositories via one git repository. Simply set the GIT_SVN_ID\r
-environment variable to a name other other than "git-svn" (the default)\r
-and git-svn will ignore the contents of the $GIT_DIR/svn/git-svn directory\r
-and instead do all of its work in $GIT_DIR/svn/$GIT_SVN_ID for that\r
-invocation. The interface branch will be remotes/$GIT_SVN_ID, instead of\r
-remotes/git-svn. Any remotes/$GIT_SVN_ID branch should never be modified\r
-by the user outside of git-svn commands.</p>\r
+SVN repositories via one git repository. Simply use the --id/-i flag or\r
+set the GIT_SVN_ID environment variable to a name other other than\r
+"git-svn" (the default) and git-svn will ignore the contents of the\r
+$GIT_DIR/svn/git-svn directory and instead do all of its work in\r
+$GIT_DIR/svn/$GIT_SVN_ID for that invocation. The interface branch will\r
+be remotes/$GIT_SVN_ID, instead of remotes/git-svn. Any\r
+remotes/$GIT_SVN_ID branch should never be modified by the user outside\r
+of git-svn commands.</p>\r
</div>\r
<h2><a id="fetch-args"></a>ADDITIONAL FETCH ARGUMENTS</h2>\r
<div class="sectionbody">\r
conflicting changeset to SVN at a bad moment (right before you commit)\r
causing a conflict and your commit to fail, your svn working tree\r
($GIT_DIR/git-svn/tree) may be dirtied. The easiest thing to do is\r
-probably just to rm -rf $GIT_DIR/git-svn/tree and run <em>rebuild</em>.</p>\r
+probably just to rm -rf $GIT_DIR/git-svn/tree and run <em>rebuild</em>. You\r
+can avoid this problem entirely by using <em>dcommit</em>.</p>\r
<p>We ignore all SVN properties except svn:executable. Too difficult to\r
map them since we rely heavily on git write-tree being _exactly_ the\r
same on both the SVN and git working trees and I prefer not to clutter\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 09-Nov-2006 23:35:41 UTC\r
+Last updated 29-Nov-2006 07:59:33 UTC\r
</div>\r
</div>\r
</body>\r
Note: You should never attempt to modify the remotes/git-svn
branch outside of git-svn. Instead, create a branch from
-remotes/git-svn and work on that branch. Use the 'commit'
+remotes/git-svn and work on that branch. Use the 'dcommit'
command (see below) to write git commits back to
remotes/git-svn.
-b<refname>::
--branch <refname>::
-Used with 'fetch' or 'commit'.
+Used with 'fetch', 'dcommit' or 'commit'.
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 an Subversion managed-project:
+Tracking and contributing to a Subversion-managed project:
------------------------------------------------------------------------
# Initialize a repo (like git init-db):
git-svn fetch
# Create your own branch to hack on:
git checkout -b my-branch remotes/git-svn
-# Commit only the git commits you want to SVN:
- git-svn commit <tree-ish> [<tree-ish_2> ...]
-# Commit all the git commits from my-branch that don't exist in SVN:
- git-svn commit remotes/git-svn..my-branch
+# Do some work, and then commit your new changes to SVN, as well as
+# automatically updating your working HEAD:
+ git-svn dcommit
# Something is committed to SVN, rebase the latest into your branch:
git-svn fetch && git rebase remotes/git-svn
# Append svn:ignore settings to the default git exclude file:
DESIGN PHILOSOPHY
-----------------
Merge tracking in Subversion is lacking and doing branched development
-with Subversion is cumbersome as a result. git-svn completely forgoes
-any automated merge/branch tracking on the Subversion side and leaves it
-entirely up to the user on the git side. It's simply not worth it to do
-a useful translation when the original signal is weak.
+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.
[[tracking-multiple-repos]]
TRACKING MULTIPLE REPOSITORIES OR BRANCHES
------------------------------------------
-This is for advanced users, most users should ignore this section.
-
Because git-svn does not care about relationships between different
branches or directories in a Subversion repository, git-svn has a simple
hack to allow it to track an arbitrary number of related _or_ unrelated
-SVN repositories via one git repository. Simply set the GIT_SVN_ID
-environment variable to a name other other than "git-svn" (the default)
-and git-svn will ignore the contents of the $GIT_DIR/svn/git-svn directory
-and instead do all of its work in $GIT_DIR/svn/$GIT_SVN_ID for that
-invocation. The interface branch will be remotes/$GIT_SVN_ID, instead of
-remotes/git-svn. Any remotes/$GIT_SVN_ID branch should never be modified
-by the user outside of git-svn commands.
+SVN repositories via one git repository. Simply use the --id/-i flag or
+set the GIT_SVN_ID environment variable to a name other other than
+"git-svn" (the default) and git-svn will ignore the contents of the
+$GIT_DIR/svn/git-svn directory and instead do all of its work in
+$GIT_DIR/svn/$GIT_SVN_ID for that invocation. The interface branch will
+be remotes/$GIT_SVN_ID, instead of remotes/git-svn. Any
+remotes/$GIT_SVN_ID branch should never be modified by the user outside
+of git-svn commands.
[[fetch-args]]
ADDITIONAL FETCH ARGUMENTS
conflicting changeset to SVN at a bad moment (right before you commit)
causing a conflict and your commit to fail, your svn working tree
($GIT_DIR/git-svn/tree) may be dirtied. The easiest thing to do is
-probably just to rm -rf $GIT_DIR/git-svn/tree and run 'rebuild'.
+probably just to rm -rf $GIT_DIR/git-svn/tree and run 'rebuild'. You
+can avoid this problem entirely by using 'dcommit'.
We ignore all SVN properties except svn:executable. Too difficult to
map them since we rely heavily on git write-tree being _exactly_ the
projects / git.git / commitdiff