git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH] remove noise and inaccuracies from git-svn docs

From
Stefan Sperling <stsp@stsp.name>
Date
Apr 18, 2011, 14:46 UTC
Message-ID
<1303138000-27807-1-git-send-email-stsp@stsp.name>
---
 Documentation/git-svn.txt |   16 +++++++---------
 1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index ea8fafd..a3b4c91 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -757,10 +757,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
 previous commits in SVN.
 
-DESIGN PHILOSOPHY
------------------
-Merge tracking in Subversion is lacking and doing branched development
-with Subversion can be cumbersome as a result.  While 'git svn' can track
+MERGE TRACKING
+--------------
+While 'git svn' can track
 copy history (including branches and tags) for repositories adopting a
 standard layout, it cannot yet represent merge history that happened
 inside git back upstream to SVN users.  Therefore it is advised that
@@ -770,16 +769,15 @@ compatibility with SVN (see the CAVEATS section below).
 CAVEATS
 -------
 
-For the sake of simplicity and interoperating with a less-capable system
-(SVN), it is recommended that all 'git svn' users clone, fetch and dcommit
+For the sake of simplicity and interoperating with Subversion,
+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'
 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 'dcommit'ing to the SVN repository.
 
 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
+plan to 'dcommit' from because Subversion users 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.
@@ -829,7 +827,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
 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
-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.
 
 CONFIGURATION
-- 
1.7.3.5
Next: Matthieu Moy
Message 1 of 16 in “remove noise and inaccuracies from git-svn docs”
  1. remove noise and inaccuracies from git-svn docsStefan Sperling, Apr 18, 2011
  2. Matthieu MoyApr 18, 2011
  3. Junio C HamanoApr 18, 2011
  4. remove noise and inaccuracies from git-svn docsStefan Sperling, Apr 19, 2011
  5. Stefan SperlingApr 19, 2011
  6. Michael J GruberApr 19, 2011
  7. Stefan SperlingApr 19, 2011
  8. Michael J GruberApr 19, 2011
  9. Piotr KrukowieckiApr 19, 2011
  10. git-svn and a new svn remote helperMatthew L Daniel, May 5, 2011
  11. Sverre RabbelierMay 5, 2011
  12. Matthew DanielMay 5, 2011
  13. Sverre RabbelierMay 5, 2011
  14. Stefan SperlingApr 28, 2011
  15. Michael SchubertApr 28, 2011
  16. Stefan SperlingApr 29, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.