4

似乎两者都不起作用--deep或--shallow似乎不起作用。git-tf checkin --deep尝试对TFS 中的新文件夹（当前为空）执行操作时出现错误。我有一个历史悠久的 git repo。作为 git-tf 的一部分，我很想保留/迁移到 TFS。

我的理解是，这checkin --deep将为每次提交在 TFS 中创建一个类似的变更集。问题是 git repo 中的任何提交似乎是合并的结果（我们在这个 repo 中有很多合并）似乎使git-tf命令非常不愉快，并报告了我在标题中提到的错误消息（带有[commitid] 的异常被替换为真实的提交 ID（例如 9a26d8））。

我不确定我是否完全错过了这里的船或什么。是否有一种可靠的方法可以将具有多个历史合并提交的预先存在的 git 存储库移植到 TFS？我希望这是一个原始功能/修复。我希望我错过了一些东西。我对 TFS 非常精通，但对 git 没有经验，因此不胜感激。

4

1 回答 1

16

这里的问题是在 TFS 中表示复杂的合并历史很困难。很简单，git 提交可以有多个父级，而 TFS 变更集只能有一个。

考虑一下我的 git 存储库在某个提交时有 HEAD 的状态，比如说9c42ef.... 现在我进行更改并提交它，创建一个新的 commit 1f23cd...。同时，我也从 Bob 那里得到一个改变，这也是一个基于9c42ef.... 他的更改是 commit ID f41ac3...。如果我想合并这两个更改，我将不得不进行合并，假设我最终得到了 commit ID 7acdfe...。现在您的图表如下所示：

          1f23cd
        /        \
9c42ef             7acdfe (HEAD)
        \        /
          f41ac3

这在 TFS 中不容易表示，因为单个变更集只能有一个祖先（直接在它之前的变更集）。所以我们需要线性化历史。这就是存在--squashand--auto-squash选项的原因git-tf checkin（在进行深度签入时）。

该--squash选项允许您在浏览历史时选择要遵循的路径。例如：

git-tf checkin --deep --squash f41ac3

f41ac3遍历图表时将省略，您将拥有三个变更集9c42ef，即1f23cd和的内容7acdfe。但是在大图中，指定每个提交到 squash 需要做很多工作。在那种情况下，--auto-squash将使用一些魔法来确定要遵循的路径。（它更喜欢具有最长提交链的路径，以便您获得尽可能多的历史记录，如果两个段长度相等，将使用时间戳来确定要遵循的路径。）

git-tf checkin --deep --auto-squash

您还可以重新设置基准，以便您签入的提交是线性的，并且每个提交只有一个父级。

git-tf开发人员根据树的复杂性、对输入无穷无尽的 SHA1 哈希字符串的受虐感受和月相来使用这些策略中的每一个。

于 2012-08-22T14:19:59.870 回答