`--prefix ""` on the command line (`--prefix=""` may not work if
your Perl's Getopt::Long is < v2.37).
+--ignore-refs=<regex>;;
+ When passed to 'init' or 'clone' this regular expression will
+ be preserved as a config key. See 'fetch' for a description
+ of `--ignore-refs`.
--ignore-paths=<regex>;;
When passed to 'init' or 'clone' this regular expression will
be preserved as a config key. See 'fetch' for a description
- of '--ignore-paths'.
+ of `--ignore-paths`.
--include-paths=<regex>;;
When passed to 'init' or 'clone' this regular expression will
be preserved as a config key. See 'fetch' for a description
- of '--include-paths'.
+ of `--include-paths`.
--no-minimize-url;;
When tracking multiple directories (using --stdlayout,
--branches, or --tags options), git svn will attempt to connect
repository. This default allows better tracking of history if
entire projects are moved within a repository, but may cause
issues on repositories where read access restrictions are in
- place. Passing '--no-minimize-url' will allow git svn to
+ place. Passing `--no-minimize-url` will allow git svn to
accept URLs as-is without attempting to connect to a higher
level directory. This option is off by default when only
one URL/branch is tracked (it would do little good).
--parent;;
Fetch only from the SVN parent of the current HEAD.
+--ignore-refs=<regex>;;
+ Ignore refs for branches or tags matching the Perl regular
+ expression. A "negative look-ahead assertion" like
+ `^refs/remotes/origin/(?!tags/wanted-tag|wanted-branch).*$`
+ can be used to allow only certain refs.
++
+[verse]
+config key: svn-remote.<name>.ignore-refs
++
+If the ignore-refs configuration key is set, and the command-line
+option is also given, both regular expressions will be used.
+
--ignore-paths=<regex>;;
This allows one to specify a Perl regular expression that will
cause skipping of all matching paths from checkout from SVN.
- The '--ignore-paths' option should match for every 'fetch'
+ The `--ignore-paths` option should match for every 'fetch'
(including automatic fetches due to 'clone', 'dcommit',
'rebase', etc) on a given repository.
+
--include-paths=<regex>;;
This allows one to specify a Perl regular expression that will
cause the inclusion of only matching paths from checkout from SVN.
- The '--include-paths' option should match for every 'fetch'
+ The `--include-paths` option should match for every 'fetch'
(including automatic fetches due to 'clone', 'dcommit',
- 'rebase', etc) on a given repository. '--ignore-paths' takes
- precedence over '--include-paths'.
+ 'rebase', etc) on a given repository. `--ignore-paths` takes
+ precedence over `--include-paths`.
+
[verse]
config key: svn-remote.<name>.include-paths
or if a second argument is passed; it will create a directory
and work within that. It accepts all arguments that the
'init' and 'fetch' commands accept; with the exception of
- '--fetch-all' and '--parent'. After a repository is cloned,
+ `--fetch-all` and `--parent`. After a repository is cloned,
the 'fetch' command will be able to update revisions without
affecting the working tree; and the 'rebase' command will be
able to update the working tree with the latest changes.
'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
+accept. However, `--fetch-all` only fetches from the current
[svn-remote], and not all [svn-remote] definitions.
+
Like 'git rebase'; this requires that the working tree be clean
(URL) may be omitted if you are working from a 'git svn'-aware
repository (that has been `init`-ed with 'git svn').
The -r<revision> option is required for this.
++
+The commit message is supplied either directly with the `-m` or `-F`
+option, or indirectly from the tag or commit when the second tree-ish
+denotes such an object, or it is requested by invoking an editor (see
+`--edit` option below).
+
+-m <msg>;;
+--message=<msg>;;
+ Use the given `msg` as the commit message. This option
+ disables the `--edit` option.
+
+-F <filename>;;
+--file=<filename>;;
+ Take the commit message from the given file. This option
+ disables the `--edit` option.
'info'::
Shows information about a file or directory similar to what
Gets the Subversion property given as the first argument, for a
file. A specific revision can be specified with -r/--revision.
+'propset'::
+ Sets the Subversion property given as the first argument, to the
+ value given as the second argument for the file given as the
+ third argument.
++
+Example:
++
+------------------------------------------------------------------------
+git svn propset svn:keywords "FreeBSD=%H" devel/py-tipper/Makefile
+------------------------------------------------------------------------
++
+This will set the property 'svn:keywords' to 'FreeBSD=%H' for the file
+'devel/py-tipper/Makefile'.
+
'show-externals'::
Shows the Subversion externals. Use -r/--revision to specify a
specific revision.
with the committer name as the first argument. The program is
expected to return a single line of the form "Name <email>",
which will be treated as if included in the authors file.
++
+[verse]
+config key: svn.authorsProg
-q::
--quiet::
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.
++
+[verse]
+config key: svn.useLogAuthor
+
--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.
-
++
+[verse]
+config key: svn.addAuthorFrom
ADVANCED OPTIONS
----------------
svn-remote.<name>.pushurl::
- Similar to Git's 'remote.<name>.pushurl', this key is designed
+ 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
Git commit to serve as parent. This will happen, among other reasons,
if the SVN branch is a copy of a revision that was not fetched by 'git
svn' (e.g. because it is an old revision that was skipped with
-'--revision'), or if in SVN a directory was copied that is not tracked
+`--revision`), or if in SVN a directory was copied that is not tracked
by 'git svn' (such as a branch that is not tracked at all, or a
subdirectory of a tracked branch). In these cases, 'git svn' will still
create a Git branch, but instead of using an existing Git commit as the
copy of a complete repository, for projects with many branches it will
lead to a working copy many times larger than just the trunk. Thus for
projects using the standard directory structure (trunk/branches/tags),
-it is recommended to clone with option '--stdlayout'. If the project
+it is recommended to clone with option `--stdlayout`. If the project
uses a non-standard structure, and/or if branches and tags are not
required, it is easiest to only clone one directory (typically trunk),
without giving any repository layout options. If the full history with
-branches and tags is required, the options '--trunk' / '--branches' /
-'--tags' must be used.
+branches and tags is required, the options `--trunk` / `--branches` /
+`--tags` must be used.
When using multiple --branches or --tags, 'git svn' does not automatically
handle name collisions (for example, if two branches from different paths have