Document that when using git svn, one should usually either use the
directory structure options to import branches as branches, or only
import one subdirectory. The default behaviour of cloning all branches
and tags as subdirectories in the working copy is usually not what the
user wants.

Signed-off-by: Sebastian Leske <>
 Documentation/git-svn.txt |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 482d60d..928a961 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -871,6 +871,16 @@ 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.
+When cloning an SVN repository, if none of the options for describing
+the repository layout is used (--trunk, --tags, --branches,
+--stdlayout), 'git svn clone' will create a git repository with
+completely linear history, where branches and tags appear as separate
+folders in the working copy.  For projects with many branches this will
+lead to a working copy many times larger than just the trunk.  It is
+recommended to either use the the options for trunk / tag / branch
+directory, or to only clone the trunk (or a subdirectory of the
 When using multiple --branches or --tags, 'git svn' does not automatically
 handle name collisions (for example, if two branches from different paths have
 the same name, or if a branch and a tag have the same name).  In these cases,

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to