在使用git-svn从一个相当大的svn仓库中拉取代码时，我遇到了以下错误消息（由于涉及实际信息，将出现一般性的信息）：
Found possible branch point: svn://server/project/trunk/dir => svn://server/project/branches/branchname, <revision>
Initializing parent: refs/remotes/branchname@<revision>
project/trunk/dir/file was not found in commit <hash> (r<revision>)
我在其他帖子中读到，通过一些调整可以“取消获取”此信息。但是，我宁愿不丢失历史记录并尽可能轻松地继续前进。
如何使git-svn fetch继续？
--ignore-paths方面不一致（最初没有办法配置它们，必须在可能获取的每个git-svn命令行上输入）。另一种方式是，svn服务器端的某个人以这样的方式更改存储库权限，以致于（从您的角度）整个子树的文件突然出现在您的git存储库中，但您的git存储库对此没有历史记录。
解决这个问题并继续执行git-svn fetch的最简单方法是使用--ignore-paths（或更好的svn-remote.svn.ignore-paths配置条目）来忽略树的问题部分。你可以通过命令行参数传递单个版本，并且在svn端有人修改它之前你不会再次遇到这个问题。
如果你想恢复而不使用--ignore-paths，那么你需要修复父修订版，使其包括被修改的文件。我专门编写了git-svn reset，以便以较少的改动来执行你所提到的“未获取”操作。它可以将你的svn远程重置回文件实际创建的位置，以便你可以将其集成到你的历史记录中。这不会清除你的工作副本，但你需要将任何工作分支重新父配到这个新的历史记录上。
git svn dcommit 时，正好有其他人提交到 SVN，这种情况发生在我身上。当进行变基操作时，git 变得非常困惑，并创建了一个提交对象，其中树仅包含本地提交修改的文件，因此看起来整个工作目录的内容都消失了。我能够使用 git svn reset 来重新获取错误的版本。 - dOxxxgit svn fetch继续同步，但是我得到了相同的错误。 - HeroCCgit svn reset <a past revision>
r1000时，运行git svn reset r990等命令。git svn rebase或git svn fetch命令。好的，我曾经为此苦苦挣扎，但找到了一个解决方法。您将失去当前git仓库版本之前文件的历史记录，但历史记录将保持完整，而且您不必使用--ignore-paths。如果重写历史是一种选择，您应该遵循Ben Jackson的git svn resetanswer。
假设您在r123上，并且没有访问scripts/文件夹，该文件夹是在r100中创建的。在某个时候，您被授予访问权限。这实际上不会生成修订版本，在SVN中是可以接受的，但在git中，它有效地重写了历史记录。git-svn仓库继续正常更新，直到修改了scripts/中的某些内容（我们称之为r126）。现在git svn fetch失败了，因为它不知道该怎么办——它有一个文件的差异，但该文件不存在！
我解决问题的方法如下：
# Clone the directory that is missing one revision before it is next changed
$ svn co -r 125 https://your-server/svn/bla/scripts
# copy the contents and (-p)reserve their attributes
$ cp -pr scripts/* ~/your-git-svn-mirror-on-r125ish/scripts
# Get the git-svn-id of the the most recent commit
$ cd ~/your-git-svn-mirror-on-r125ish
$ git log -1 | grep git-svn-id
git-svn-id: https://your-server/svn/bla/trunk@125 7b6d...daf
git-svn-id是问题的关键。它告诉git-svn每个修订版本映射到哪个提交。我们要欺骗它，让它认为我们手动提交的实际上是一个SVN提交。# Add the missing new directory
$ git add scripts/
# An editor will open up, type a message warning this commit isn't a real svn revision
# The last line of your message should be the 'git-svn-id' from earlier.
$ git commit
<your message of warning>
git-svn-id: https://your-server/svn/bla/trunk@125 7b6d...daf
# Backup the svn state in case something goes wrong
$ mv .git/svn .git/svn-BACKUP
# Cross your fingers, and fetch the changes from svn
# If your repo is large, it may take a long time to rebuild the mappings
$ git svn fetch
git svn rebase和git push。虽然可能不是最优美的解决方案，但在git version 2.17.1中有效。git-svn 了，但是我记得那个 git-svn-id 的注释只有在 .git/svn 目录的索引丢失时才会被使用。因此，如果你需要加快这个工作流程的速度，你可以尝试更新索引而不是强制从头开始重建它。 - Ben Jacksongit svn fetch --ignore-paths path/up/to/filename，其中包括文件的完整路径，但没有起作用。尝试使用包含Unicode字符的目录的完整路径也不行。最终有效的命令是使用包含Unicode字符的目录的父目录，如下所示：git svn fetch --ignore-paths path/up/to/but-not-including-unicode-chars
在Windows系统中，文件名中包含特殊字符（如umlauts）时出现了相同的错误：
(...)
r36770 = 24d589b34b952dd13ee8d231e7ce4d675ec1a82c (refs/remotes/origin/xxx)
M doc/specification/xxx/2013 03 07 Workflows.xls
xxx/branches/xxx/doc/specification/xxx/2013 03 07 München.xls
was not found in commit 24d589b34b952dd13ee8d231e7ce4d675ec1a82c (r36770)
这个文件确实在引用的版本中，但是git svn无法看到它。
我通过设置语言和区域环境变量来解决了这个问题，像这样：
SET LANG=C
SET LC_ALL=C
在运行git svn之前，您可以简单地执行这些命令，但它们只会在当前shell存在的时间内持续存在。如果您想永久设置它们，请前往控制面板>系统>高级系统设置>环境变量。
对于较新的MacOSX系统进行配置
git config --global core.precomposeunicode false
, 对于旧版 true。 在这里解释：
https://michael-kuehnel.de/git/2014/11/21/git-mac-osx-and-german-umlaute.html
正确设置配置选项后，我能够使用svn2git（它在底层使用git svn）导入SVN存储库。
我还遇到了
$ locale
LANG="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_CTYPE="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_ALL="de_DE.UTF-8"
但我怀疑这并没有什么区别。
git svn reset -r <previous>然后执行git svn fetch- the_mandrill