The git-foo forms are deprecated in favour of "git foo" Signed-off-by: Peter <git@xxxxxxxxxxxxxxxxxxx> --- Documentation/git-svn.txt | 50 ++++++++++++++++++++++---------------------- 1 files changed, 25 insertions(+), 25 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index b1d527f..f94d0f9 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -97,20 +97,20 @@ COMMANDS 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 dcommiting with git-svn. +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 dcommiting with git-svn. -This accepts all options that 'git-svn fetch' and 'git-rebase' +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 +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 + Do not fetch remotely; only run 'git rebase' against the last fetched commit from the upstream SVN. 'dcommit':: @@ -313,7 +313,7 @@ config key: svn.repackflags 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). +'git reset' cannot be used (see dcommit). -n:: --dry-run:: @@ -366,7 +366,7 @@ 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. -The 'git-svn log' command will not work on repositories using +The 'git svn log' command will not work on repositories using this, either. Using this conflicts with the 'useSvmProps' option for (hopefully) obvious reasons. @@ -414,7 +414,7 @@ Tracking and contributing to the trunk of a Subversion-managed project: ------------------------------------------------------------------------ # Clone a repo (like git clone): - git-svn clone http://svn.foo.org/project/trunk + 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 @@ -423,12 +423,12 @@ Tracking and contributing to the trunk of a Subversion-managed project: git commit ... # Something is committed to SVN, rebase your local changes against the # latest changes in SVN: - git-svn rebase + 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 + git svn dcommit # Append svn:ignore settings to the default git exclude file: - git-svn show-ignore >> .git/info/exclude + git svn show-ignore >> .git/info/exclude ------------------------------------------------------------------------ Tracking and contributing to an entire Subversion-managed project @@ -436,7 +436,7 @@ Tracking and contributing to an entire Subversion-managed project ------------------------------------------------------------------------ # Clone a repo (like git clone): - git-svn clone http://svn.foo.org/project -T trunk -b branches -t tags + 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' @@ -446,27 +446,27 @@ Tracking and contributing to an entire Subversion-managed project # of dcommit/rebase/show-ignore should be the same as above. ------------------------------------------------------------------------ -The initial 'git-svn clone' can be quite time-consuming +The initial 'git svn clone' can be quite time-consuming (especially for large Subversion repositories). If multiple people (or one person with multiple machines) want to use git-svn to interact with the same Subversion repository, you can -do the initial 'git-svn clone' to a repository on a server and +do the initial 'git svn clone' to a repository on a server and have each person clone that repository with 'git clone': ------------------------------------------------------------------------ # Do the initial import on a server - ssh server "cd /pub && git-svn clone http://svn.foo.org/project + ssh server "cd /pub && git svn clone http://svn.foo.org/project # Clone locally - make sure the refs/remotes/ space matches the server mkdir project cd project - git-init + git init git remote add origin server:/pub/project git config --add remote.origin.fetch=+refs/remotes/*:refs/remotes/* git fetch # Initialize git-svn locally (be sure to use the same URL and -T/-b/-t options as were used on server) - git-svn init http://svn.foo.org/project + git svn init http://svn.foo.org/project # Pull the latest changes from Subversion - git-svn rebase + git svn rebase ------------------------------------------------------------------------ REBASE VS. PULL/MERGE @@ -474,12 +474,12 @@ REBASE VS. PULL/MERGE Originally, git-svn recommended that the remotes/git-svn branch be 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. +'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 +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-svn 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. @@ -504,14 +504,14 @@ 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 dcommiting to the SVN repository. -Running 'git-merge' or 'git-pull' is NOT recommended on a branch you +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 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. -'git-clone' does not clone branches under the refs/remotes/ hierarchy or +'git clone' does not clone branches under the refs/remotes/ hierarchy or any git-svn metadata, or config. So repositories created and managed with using git-svn should use rsync(1) for cloning, if cloning is to be done at all. -- 1.5.3.7 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
