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 <sebastian.leske@xxxxxxxxxxx> --- 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 +trunk). + 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, -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html