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

[PATCH] git-svn: update documentation with CAVEATS section

From
EWEric Wong <normalperson@yhbt.net>
Date
Aug 16, 2007, 08:56 UTC
Message-ID
<20070816085645.GA3159@soma>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
  I've been meaning to do this for a while, hopefully this cuts
  down on the redundant mailing list traffic about these subjects.
 Documentation/git-svn.txt |   32 ++++++++++++++++++++++++++++++++
 1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 816340b..fbc5887 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -479,6 +479,38 @@ the user on the git side.  git-svn does however follow copy
 history of the directory that it is tracking, however (much like
 how 'svn log' works).
 
+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
+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 dcommiting 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
+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
+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.
+
+Since 'dcommit' uses rebase internally, any git branches you git-push to
+before dcommit on will require forcing an overwrite of the existing ref
+on the remote repository.  This is generally considered bad practice,
+see the git-push(1) documentation for details.
+
+Do not use the --amend option of git-commit(1) on a change you've
+already dcommitted.  It is considered bad practice to --amend commits
+you've already pushed to a remote repository for other users, and
+dcommit with SVN is analogous to that.
+
 BUGS
 ----
 
-- 
Eric Wong
Next: Junio C Hamano
Message 1 of 7 in “git-svn: update documentation with CAVEATS section”
  1. git-svn: update documentation with CAVEATS sectionEric Wong, Aug 16, 2007
  2. Junio C HamanoAug 22, 2007
  3. David KastrupAug 22, 2007
  4. Eric WongAug 23, 2007
  5. David KastrupAug 23, 2007
  6. Eric WongAug 23, 2007
  7. David KastrupAug 23, 2007

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.