Merge branch 'jc/rename-degrade-cc-to-c' into maint

[git.git] / Documentation / git-svn.txt

diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index ea8fafd18a7e5f79a017f0f6ea0bbfdbf947461b..39feb62129d9527f08db69175bcba19ea5d253aa 100644 (file)
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -145,17 +145,6 @@ Skip "branches" and "tags" of first level directories;;
 ------------------------------------------------------------------------
 --
 
---use-log-author;;
-       When retrieving svn commits into git (as part of fetch, rebase, or
-       dcommit operations), look for the first From: or Signed-off-by: line
-       in the log message and use that as the author string.
---add-author-from;;
-       When committing to svn from git (as part of commit or dcommit
-       operations), if the existing log message doesn't already have a
-       From: or Signed-off-by: line, append a From: line based on the
-       git commit's author string.  If you use this, then --use-log-author
-       will retrieve a valid author string for all commits.
-
 'clone'::
        Runs 'init' and 'fetch'.  It will automatically create a
        directory based on the basename of the URL passed to it;
@@ -217,6 +206,13 @@ config key: svn.commiturl (overwrites all svn-remote.<name>.commiturl options)
 Using this option for any other purpose (don't ask) is very strongly
 discouraged.
 
+--mergeinfo=<mergeinfo>;;
+       Add the given merge information during the dcommit
+       (e.g. `--mergeinfo="/branches/foo:1-10"`). All svn server versions can
+       store this information (as a property), and svn clients starting from
+       version 1.5 can make use of it. 'git svn' currently does not use it
+       and does not set it automatically.
+
 'branch'::
        Create a branch in the SVN repository.
 
@@ -565,6 +561,17 @@ repository that will be fetched from.
 For 'branch' and 'tag', display the urls that will be used for copying when
 creating the branch or tag.
 
+--use-log-author::
+       When retrieving svn commits into git (as part of 'fetch', 'rebase', or
+       'dcommit' operations), look for the first `From:` or `Signed-off-by:` line
+       in the log message and use that as the author string.
+--add-author-from::
+       When committing to svn from git (as part of 'commit-diff', 'set-tree' or 'dcommit'
+       operations), if the existing log message doesn't already have a
+       `From:` or `Signed-off-by:` line, append a `From:` line based on the
+       git commit's author string.  If you use this, then `--use-log-author`
+       will retrieve a valid author string for all commits.
+
 
 ADVANCED OPTIONS
 ----------------
@@ -648,6 +655,16 @@ svn-remote.<name>.rewriteUUID::
        where the original UUID is not available via either useSvmProps
        or useSvnsyncProps.
 
+svn-remote.<name>.pushurl::
+
+       Similar to git's 'remote.<name>.pushurl', this key is designed
+       to be used in cases where 'url' points to an SVN repository
+       via a read-only transport, to provide an alternate read/write
+       transport. It is assumed that both keys point to the same
+       repository. Unlike 'commiturl', 'pushurl' is a base path. If
+       either 'commiturl' or 'pushurl' could be used, 'commiturl'
+       takes precedence.
+
 svn.brokenSymlinkWorkaround::
        This disables potentially expensive checks to workaround
        broken symlinks checked into SVN by broken clients.  Set this
@@ -757,10 +774,9 @@ use `git svn rebase` to update your work branch instead of `git pull` or
 when committing into SVN, which can lead to merge commits reversing
 previous commits in SVN.
 
-DESIGN PHILOSOPHY
------------------
-Merge tracking in Subversion is lacking and doing branched development
-with Subversion can be cumbersome as a result.  While 'git svn' can track
+MERGE TRACKING
+--------------
+While 'git svn' can track
 copy history (including branches and tags) for repositories adopting a
 standard layout, it cannot yet represent merge history that happened
 inside git back upstream to SVN users.  Therefore it is advised that
@@ -770,16 +786,15 @@ compatibility with SVN (see the CAVEATS section below).
 CAVEATS
 -------
 
-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
+For the sake of simplicity and interoperating with Subversion,
+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'
 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.
 
 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
+plan to 'dcommit' from because Subversion users 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.
@@ -829,7 +844,7 @@ Renamed and copied directories are not detected by git and hence not
 tracked when committing to SVN.  I do not plan on adding support for
 this as it's quite difficult and time-consuming to get working for all
 the possible corner cases (git doesn't do it, either).  Committing
-renamed and copied files are fully supported if they're similar enough
+renamed and copied files is fully supported if they're similar enough
 for git to detect them.
 
 CONFIGURATION