Git-TFS 有一个验证命令，帮助描述如下：“验证命令有助于识别从 TFS 获取、克隆或快速克隆的不准确性。” 我有一个专有存储库，我正在从 TFS 迁移到 Git。运行git tfs verify显示我的 Git 存储库中有大量文件丢失，这些文件存在于 TFS 中，并且在进行同步之后立即出现。这种情况以前发生过一次，我炸毁了整个存储库并重新开始，但现在我又遇到了同样的问题。我之前已经使用 Git-TFS 成功克隆了这个存储库（在我们开始迁移到 Git 之前，当时我只是在本地使用它）所以我知道它可以成功，但我宁愿不炸毁整个存储库并重新开始。
是否有一种自动方法来修补 verify 命令显示的差异，而无需重新克隆整个 repo？我可以在 TFS 中检查项目并在必要时手动复制所有文件，但我希望有更好的方法。
我希望某种命令类似于git tfs repair验证命令。然而，代替找到类似的东西，我能够以两种不同的方式解决这个问题。我有两个存储库被搞砸了，其中一个我有另一个很好的副本（在部门开始从 TFS 迁移到 Git 之前，我已经成功地克隆了它以供我自己私人使用 Git）。另一个我没有预先存在的副本，每次我尝试克隆它时都会遇到同样的问题。
之前的两个解决方案可以修补回购的当前状态，但当然没有说出历史的真相。如果有任何可能的方法来做一些类似的事情，那还是很好的git tfs repair。
我将我的好回购作为远程添加到我试图修补的回购中：
git remote add goodclone C:/path/to/good/clone
然后我从那个远程获取：
git fetch goodclone
Git 发出警告，指出所有提交都不相同（这是因为它们已在不同时间通过 Git-TFS 从 TFS 克隆）。我知道这是真的，所以没关系。这只是意味着克隆需要更长的时间。
我签出了一个分支master来做这项工作。
git checkout -b repair
我还从 good repo 的遥控器中检查了一个分支，这是一个很好的衡量标准：
git checkout -b goodclone-master goodclone/master
然后我合并：
git checkout repair
git merge --squash goodclone-master
我不得不修补一些东西，然后我承诺了。我再次运行 TFS-Git 同步过程，切换到 master 并拉下最新的更改，重新设置 master 上的修复分支，将其合并到 master，然后推送。
据我所知，现在情况很好！
我通过 TFS 克隆了存储库，然后使用 Vim 从 verify 命令的输出创建了一个脚本，以从 TFS 存储库复制文件。在脚本中，我必须mkdir -p在复制文件之前对包含目录进行操作。然后我提交了文件来修补。它似乎有效，但有点像黑客。