我正在尝试将 SVN 存储库转换为多个 git 存储库。到目前为止，我一直在使用git svn clone svn_repo_project_pathSVN 中的每个项目。我注意到 git 似乎没有遵循 svn 复制操作，因此生成的历史比我预期的要简短得多。假设我的 SVN 存储库看起来像这样：
根
b作为重组工作的一部分，项目c最近被复制parent-proj，目的是最终将它们从根目录下的旧位置删除。当我这样做时git svn clone http://svnhost/parent-proj，生成的 git repo 丢失了所有源自迁移之前和迁移之前的历史/b记录/c。
这是 git-svn 的限制，还是有什么方法可以让这段历史出现在我的仓库中？从我有限的研究来看，使用 git-svn 重命名的 SVN repo 的完整历史中filter-branch描述的命令似乎可以工作，尽管在我的情况下，有多个父母可能会使事情复杂化。可以先克隆整个回购然后从中分离出新的回购（使用过滤器分支？）是更好的方法吗？
b如果c您git svn clone http://svnhost/parent-proj. _ git svn将您提供的基本路径解释为您有兴趣摄取 SVN 提交的最浅点，从而使 Git 提交相同。由于历史提交在这条路径下b和c之外，git svn不会镜像它们，所以你不会有那个历史。
查看该git svn init --no-minimize-url选项的文档：
当跟踪多个目录（使用 --stdlayout、--branches 或 --tags 选项）时，git svn 将尝试连接到 Subversion 存储库的根目录（或允许的最高级别）。如果整个项目在存储库中移动，此默认设置允许更好地跟踪历史记录，但可能会导致存在读取访问限制的存储库出现问题。传递 --no-minimize-url 将允许 git svn 按原样接受 URL，而无需尝试连接到更高级别的目录。当只跟踪一个 URL/分支时，此选项默认关闭（它不会有什么好处）。
由于您的clone命令没有指定多个分支（可能是因为您有一个复杂的、多项目或非标准布局），git svn因此只需克隆涉及该路径和向下的提交。Shadow Creeper 在评论中使用了-sor--stdlayout选项，这可以解释为什么为他们保留了一些历史。
如果这是一次性转换（从 SVN 到 Git 的单向移动），那么您可能应该克隆整个存储库，那么您可以在 Git 中移动东西以使其看起来像您想要的那样，包括建立历史分支和标签。如果运行的动机filter-branch是节省存储库空间，请确保这实际上会为您节省一些东西，并且值得费心。Git 在存储方面非常高效。
最后要注意的是对 Git 克隆中历史搜索的期望。使用 查找文件的历史记录git log -C --follow <file-path>，Git 通常会很好地定位并为您提供包含重命名和副本的历史记录。不要期望目录也一样，例如parent-proj/b. Git 跟踪 blob（文件）、树（blob）、提交和父提交，但不像 SVN 那样处理目录或目录副本。