argument. Normally this command initializes the current
directory.
--T<trunk_subdir>::
---trunk=<trunk_subdir>::
--t<tags_subdir>::
---tags=<tags_subdir>::
--b<branches_subdir>::
---branches=<branches_subdir>::
+-T<trunk_subdir>;;
+--trunk=<trunk_subdir>;;
+-t<tags_subdir>;;
+--tags=<tags_subdir>;;
+-b<branches_subdir>;;
+--branches=<branches_subdir>;;
These are optional command-line options for init. Each of
these flags can point to a relative repository path
(--tags=project/tags') or a full url
(--tags=https://foo.org/project/tags)
-
---prefix=<prefix>
+--no-metadata;;
+ Set the 'noMetadata' option in the [svn-remote] config.
+--use-svm-props;;
+ Set the 'useSvmProps' option in the [svn-remote] config.
+--use-svnsync-props;;
+ Set the 'useSvnsyncProps' option in the [svn-remote] config.
+--rewrite-root=<URL>;;
+ Set the 'rewriteRoot' option in the [svn-remote] config.
+--username=<USER>;;
+ For transports that SVN handles authentication for (http,
+ https, and plain svn), specify the username. For other
+ transports (eg svn+ssh://), you must include the username in
+ the URL, eg svn+ssh://foo@svn.bar.com/project
+--prefix=<prefix>;;
This allows one to specify a prefix which is prepended
to the names of remotes if trunk/branches/tags are
specified. The prefix does not automatically include a
repository.
'fetch'::
-
Fetch unfetched revisions from the Subversion remote we are
tracking. The name of the [svn-remote "..."] section in the
.git/config file may be specified as an optional command-line
argument.
+'clone'::
+ Runs 'init' and 'fetch'. It will automatically create a
+ directory based on the basename of the URL passed to it;
+ 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'. 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.
+
+'rebase'::
+ This fetches revisions from the SVN parent of the current HEAD
+ and rebases the current (uncommitted to SVN) work against it.
+
+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 dcommit-ing with git-svn.
+
+This accepts all options that 'git-svn fetch' and 'git-rebase'
+accepts. 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
+and have no uncommitted changes.
+
+-l;;
+--local;;
+ Do not fetch remotely; only run 'git-rebase' against the
+ last fetched commit from the upstream SVN.
+
'dcommit'::
Commit each diff from a specified head directly to the SVN
repository, and then rebase or reset (depending on whether or
alternative to HEAD.
This is advantageous over 'set-tree' (below) because it produces
cleaner, more linear history.
++
+--no-rebase;;
+ After committing, do not rebase or reset.
+--
'log'::
This should make it easy to look up svn log messages when svn
users refer to -r/--revision numbers.
++
+The following features from `svn log' are supported:
++
+--
+--revision=<n>[:<n>];;
+ is supported, non-numeric args are not:
+ HEAD, NEXT, BASE, PREV, etc ...
+-v/--verbose;;
+ it's not completely compatible with the --verbose
+ output in svn log, but reasonably close.
+--limit=<n>;;
+ is NOT the same as --max-count, doesn't count
+ merged/excluded commits
+--incremental;;
+ supported
+--
++
+New features:
++
+--
+--show-commit;;
+ shows the git commit sha1, as well
+--oneline;;
+ our version of --pretty=oneline
+--
++
+Any other arguments are passed directly to `git log'
- The following features from `svn log' are supported:
-
- --revision=<n>[:<n>] - is supported, non-numeric args are not:
- HEAD, NEXT, BASE, PREV, etc ...
- -v/--verbose - it's not completely compatible with
- the --verbose output in svn log, but
- reasonably close.
- --limit=<n> - is NOT the same as --max-count,
- doesn't count merged/excluded commits
- --incremental - supported
-
- New features:
-
- --show-commit - shows the git commit sha1, as well
- --oneline - our version of --pretty=oneline
-
- Any other arguments are passed directly to `git log'
+--
+'find-rev'::
+ When given an SVN revision number of the form 'rN', returns the
+ corresponding git commit hash (this can optionally be followed by a
+ tree-ish to specify which branch should be searched). When given a
+ tree-ish, returns the corresponding SVN revision number.
'set-tree'::
You should consider using 'dcommit' instead of this command.
Make git-svn less verbose.
--repack[=<n>]::
---repack-flags=<flags>
- These should help keep disk usage sane for large fetches
- with many revisions.
+--repack-flags=<flags>::
+
+These should help keep disk usage sane for large fetches
+with many revisions.
- --repack takes an optional argument for the number of revisions
- to fetch before repacking. This defaults to repacking every
- 1000 commits fetched if no argument is specified.
+--repack takes an optional argument for the number of revisions
+to fetch before repacking. This defaults to repacking every
+1000 commits fetched if no argument is specified.
- --repack-flags are passed directly to gitlink:git-repack[1].
+--repack-flags are passed directly to gitlink:git-repack[1].
+[verse]
config key: svn.repack
config key: svn.repackflags
-s<strategy>::
--strategy=<strategy>::
-These are only used with the 'dcommit' command.
+These are only used with the 'dcommit' and 'rebase' commands.
Passed directly to git-rebase when using 'dcommit' if a
'git-reset' cannot be used (see dcommit).
config key: svn.followparent
-svn.noMetadata:
-svn-remote.<name>.noMetadata:
- This gets rid of the git-svn-id: lines at the end of every commit.
+--
+CONFIG FILE-ONLY OPTIONS
+------------------------
+--
+
+svn.noMetadata::
+svn-remote.<name>.noMetadata::
- If you lose your .git/svn/git-svn/.rev_db file, git-svn will not
- be able to rebuild it and you won't be able to fetch again,
- either. This is fine for one-shot imports.
+This gets rid of the git-svn-id: lines at the end of every commit.
- The 'git-svn log' command will not work on repositories using
- this, either. Using this conflicts with the 'useSvmProps'
- option for (hopefully) obvious reasons.
+If you lose your .git/svn/git-svn/.rev_db file, git-svn will not
+be able to rebuild it and you won't be able to fetch again,
+either. This is fine for one-shot imports.
-svn.useSvmProps:
-svn-remote.<name>.useSvmProps:
- This allows git-svn to re-map repository URLs and UUIDs from
- mirrors created using SVN::Mirror (or svk) for metadata.
+The 'git-svn log' command will not work on repositories using
+this, either. Using this conflicts with the 'useSvmProps'
+option for (hopefully) obvious reasons.
- If an SVN revision has a property, "svm:headrev", it is likely
- that the revision was created by SVN::Mirror (also used by SVK).
- The property contains a repository UUID and a revision. We want
- to make it look like we are mirroring the original URL, so
- introduce a helper function that returns the original identity
- URL and UUID, and use it when generating metadata in commit
- messages.
+svn.useSvmProps::
+svn-remote.<name>.useSvmProps::
- Using this conflicts with the 'noMetadata' option for
- (hopefully) obvious reasons.
+This allows git-svn to re-map repository URLs and UUIDs from
+mirrors created using SVN::Mirror (or svk) for metadata.
+
+If an SVN revision has a property, "svm:headrev", it is likely
+that the revision was created by SVN::Mirror (also used by SVK).
+The property contains a repository UUID and a revision. We want
+to make it look like we are mirroring the original URL, so
+introduce a helper function that returns the original identity
+URL and UUID, and use it when generating metadata in commit
+messages.
+
+svn.useSvnsyncProps::
+svn-remote.<name>.useSvnsyncprops::
+ Similar to the useSvmProps option; this is for users
+ of the svnsync(1) command distributed with SVN 1.4.x and
+ later.
+
+svn-remote.<name>.rewriteRoot::
+ This allows users to create repositories from alternate
+ URLs. For example, an administrator could run git-svn on the
+ server locally (accessing via file://) but wish to distribute
+ the repository with a public http:// or svn:// URL in the
+ metadata so users of it will see the public URL.
+
+Since the noMetadata, rewriteRoot, useSvnsyncProps and useSvmProps
+options all affect the metadata generated and used by git-svn; they
+*must* be set in the configuration file before any history is imported
+and these settings should never be changed once they are set.
+
+Additionally, only one of these four options can be used per-svn-remote
+section because they affect the 'git-svn-id:' metadata line.
--
-Basic Examples
-~~~~~~~~~~~~~~
+BASIC EXAMPLES
+--------------
Tracking and contributing to a the trunk of a Subversion-managed project:
------------------------------------------------------------------------
-# Initialize a repo (like git init):
- git-svn init http://svn.foo.org/project/trunk
-# Fetch remote revisions:
- git-svn fetch
-# Create your own branch to hack on:
- git checkout -b my-branch remotes/git-svn
-# Do some work, and then commit your new changes to SVN, as well as
-# automatically updating your working HEAD:
+# Clone a repo (like git clone):
+ git-svn clone http://svn.foo.org/project/trunk
+# Enter the newly cloned directory:
+ cd trunk
+# You should be on master branch, double-check with git-branch
+ git branch
+# Do some work and commit locally to git:
+ git commit ...
+# Something is committed to SVN, rebase your local changes against the
+# latest changes in SVN:
+ git-svn rebase
+# Now commit your changes (that were committed previously using git) 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:
git-svn show-ignore >> .git/info/exclude
------------------------------------------------------------------------
(complete with a trunk, tags and branches):
------------------------------------------------------------------------
-# Initialize a repo (like git init):
- git-svn init http://svn.foo.org/project -T trunk -b branches -t tags
-# Fetch remote revisions:
- git-svn 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
-# Something has been committed to trunk, rebase the latest into your branch:
- git-svn 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
+# Clone a repo (like git clone):
+ git-svn clone http://svn.foo.org/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'
+# with the appropriate name):
+ git reset --hard remotes/trunk
+# You may only dcommit to one branch/tag/trunk at a time. The usage
+# of dcommit/rebase/show-ignore should be the same as above.
------------------------------------------------------------------------
REBASE VS. PULL/MERGE
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
+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
when committing into SVN, which can lead to merge commits reversing
previous commits in SVN.
BUGS
----
-We ignore all SVN properties except svn:executable. Too difficult to
-map them since we rely heavily on git write-tree being _exactly_ the
-same on both the SVN and git working trees and I prefer not to clutter
-working trees with metadata files.
+We ignore all SVN properties except svn:executable. Any unhandled
+properties are logged to $GIT_DIR/svn/<refname>/unhandled.log
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). Renamed and
-copied files are fully supported if they're similar enough for git to
-detect them.
+the possible corner cases (git doesn't do it, either). Committing
+renamed and copied files are fully supported if they're similar enough
+for git to detect them.
CONFIGURATION
-------------