我的问题乍一看与其他问题相似（特别是使用 Git-Svn 克隆非标准 Svn 存储库），但我还有一个问题。我也知道http://john.albin.net/git/git-svn-migrate。
在 svn 存储库中创建的一些分支忽略了主干中的顶级目录。因此，在分支中，所有文件似乎都与主干中的文件不同，仅仅是因为它们位于不同的位置。
示例：在其中一个分支中，目录trunk/top/src对应于branches/foo/bar/src而不是更常见的branches/foo/bar/top/src. 但也有使用第二种形式的分支。
现在，当git svn clone在这个 svn 存储库上运行时，它将重新跟踪此类分支的完整历史记录并将所有对它们的提交加倍。在主干上，提交将用于文件top/src/file，在分支上将用于src/file. 因为这个git svn fetch操作显然不够聪明，无法检测到这个重定位，所以它会返回创建分支之前的完整历史并为新位置创建新的提交，一直追溯到时间的开始，就这样它可以创建进入分支的文件。
由于有很多分支，而后面的分支有很多历史记录，这是令人讨厌的情况，因为每次提交都会增加一倍或三倍（尽管从粗略的检查来看，似乎每个文件的“备用”位置都是共享的一些但不是所有的分支的史前历史，它稍后将发生）。它也确实增加了转换时间。
现在我一直在考虑解决以下问题。如果可以在git svn fetch（它是一个 Perl 脚本）的代码中插入一些钩子，它会在它从 svn 获取文件之后，但在将它们提交到 git 之前编辑所涉及文件的路径。如果文件的路径名不包含top目录，则将其插入，否则将单独保留名称。通过这种方式，我可以有效地改写历史。
现在想到以下问题：
- 这是一个理智的想法吗？
- 如果是，我该怎么做？
- 如果没有，我还能做什么？原始存储库仍在使用中，因此无法或难以导入未来提交的解决方案很遗憾没有帮助。
除此之外，我将从一个非空的目标存储库开始，并跳过 svn 历史的第一部分。这是因为开头是从 cvs 转换而来的，从那时起它的标签以一种相当奇怪和无用的方式转换，我已经创建了一个脚本来从头开始重新做那部分。
（是的，截至 2019 年，我仍在寻找答案……）