development/git
development/git
1
0
Fork 0
mirror of https://github.com/git/git synced 2024-08-25 10:45:59 +00:00
Code Issues Packages Projects Releases Wiki Activity

git-svn: clarify the referent of dcommit's optional argument

Browse source 
The documentation of the dcommit subcommand is reworded to clarify that
the optional argument refers to a git branch, not an SVN branch.

The discussion of the optional argument is put into its own paragraph
as is the guidance about using 'dcommit' in preference to 'set-tree'.

The section on REBASE vs. PULL/MERGE is reworded to incorporate the
advice to prefer 'git rebase' previously in the description of 'dcommit'.

Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
This commit is contained in:
Jon Seymour 2012-05-17 13:20:43 +10:00 committed by Eric Wong
parent b64e1f5815
commit 2b26b65f9a
1 changed files with 18 additions and 19 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

37
Documentation/git-svn.txt
View file

@ -189,18 +189,16 @@ and have no uncommitted changes.
last fetched commit from the upstream SVN. last fetched commit from the upstream SVN.
'dcommit':: 'dcommit'::
Commit each diff from a specified head directly to the SVN Commit each diff from the current branch directly to the SVN
repository, and then rebase or reset (depending on whether or repository, and then rebase or reset (depending on whether or
not there is a diff between SVN and head). This will create not there is a diff between SVN and head). This will create
a revision in SVN for each commit in git. a revision in SVN for each commit in git.
It is recommended that you run 'git svn' fetch and rebase (not +
pull or merge) your commits against the latest changes in the When an optional git branch name (or a git commit object name)
SVN repository. is specified as an argument, the subcommand works on the specified
An optional revision or branch argument may be specified, and branch, not on the current branch.
causes 'git svn' to do all work on that revision/branch +
instead of HEAD. Use of 'dcommit' is preferred to 'set-tree' (below).
This is advantageous over 'set-tree' (below) because it produces
cleaner, more linear history.
+ +
--no-rebase;; --no-rebase;;
After committing, do not rebase or reset. After committing, do not rebase or reset.
@ -802,18 +800,19 @@ have each person clone that repository with 'git clone':
REBASE VS. PULL/MERGE REBASE VS. PULL/MERGE
--------------------- ---------------------
Prefer to use 'git svn rebase' or 'git rebase', rather than
'git pull' or 'git merge' to synchronize unintegrated commits with a 'git svn'
branch. Doing so will keep the history of unintegrated commits linear with
respect to the upstream SVN repository and allow the use of the preferred
'git svn dcommit' subcommand to push unintegrated commits back into SVN.
Originally, 'git svn' recommended that the 'remotes/git-svn' branch be Originally, 'git svn' recommended that developers pulled or merged from
pulled or merged from. This is because the author favored the 'git svn' branch. This was because the author favored
`git svn set-tree B` to commit a single head rather than the `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 A..B` notation to commit multiple commits. Use of
'git pull' or 'git merge' with `git svn set-tree A..B` will cause non-linear
If you use `git svn set-tree A..B` to commit several diffs and you do history to be flattened when committing into SVN and this can lead to merge
not have the latest remotes/git-svn merged into my-branch, you should commits unexpectedly reversing previous commits in SVN.
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.
MERGE TRACKING MERGE TRACKING
-------------- --------------