undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'ss/doc-svn'

Browse Source 
* ss/doc-svn:
  remove noise and inaccuracies from git-svn docs
This commit is contained in:
Junio C Hamano 2011-05-04 15:51:43 -07:00
commit a211e6712b
1 changed files with 7 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
Documentation/git-svn.txt
View File

@ -784,10 +784,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 when committing into SVN, which can lead to merge commits reversing
previous commits in SVN. previous commits in SVN.
DESIGN PHILOSOPHY MERGE TRACKING
----------------- --------------
Merge tracking in Subversion is lacking and doing branched development While 'git svn' can track
with Subversion can be cumbersome as a result. While 'git svn' can track
copy history (including branches and tags) for repositories adopting a copy history (including branches and tags) for repositories adopting a
standard layout, it cannot yet represent merge history that happened standard layout, it cannot yet represent merge history that happened
inside git back upstream to SVN users. Therefore it is advised that inside git back upstream to SVN users. Therefore it is advised that
@ -797,16 +796,15 @@ compatibility with SVN (see the CAVEATS section below).
CAVEATS CAVEATS
------- -------
For the sake of simplicity and interoperating with a less-capable system For the sake of simplicity and interoperating with Subversion,
(SVN), it is recommended that all 'git svn' users clone, fetch and dcommit 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' directly from the SVN server, and avoid all 'git clone'/'pull'/'merge'/'push'
operations between git repositories and branches. The recommended operations between git repositories and branches. The recommended
method of exchanging code between git branches and users is method of exchanging code between git branches and users is
'git format-patch' and 'git am', or just 'dcommit'ing to the SVN repository. '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 Running 'git merge' or 'git pull' is NOT recommended on a branch you
plan to 'dcommit' from. Subversion does not represent merges in any plan to 'dcommit' from because Subversion users cannot see 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 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 that is a mirror of an SVN branch, 'dcommit' may commit to the wrong
branch. branch.
@ -856,7 +854,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 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 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 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. for git to detect them.
CONFIGURATION CONFIGURATION