Question

我的任务是迁移我的团队和从git到Perforce的源代码，我正在寻找有关如何将git历史记录转换为p4的想法。

我很乐意只移动主分支。然而，即使这证明是有问题的。

我正在使用精彩的git-p4工具。我在p4工作区中创建了一个目标区域，并使用git p4 clone //depot/StuffFromGit开始在git-p4中跟踪它。我将所有git存储库的更改移植到git-p4克隆中。然后我可以git p4 submit完成，所有更改都推送到p4。

当git历史看起来像这样，很好且线性时，它很有用：

A---B---C---D

问题来自于多个人参与该项目。即使他们正在使用master，仍然会创建分割和合并的分支。不过，git-p4勇敢地处理了这个问题：

A---B---C---E
     \--D--/

git p4遍历OK，按顺序提交ABCDE（或ABDCE，任何一个人的历史记录）。

问题来自于，例如，C和D都改变了同一个文件，而E是一个真实的诚实合并。 git p4 rebase在这里失败了;它将回滚提交，但在回放期间它将首先应用C，然后尝试D并找到冲突。它会停下来，让我合并。好吧，E包含合并，但它要求我手动合并！ 'git p4 submit'将以类似的方式失败，只是现在它是p4拒绝合并前的更改。

Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging main.cpp
CONFLICT (content): Merge conflict in main.cpp
Failed to merge in the changes.
Patch failed at 0005 Changing main

所以现在我被卡住了。有没有办法消毒git历史或让git-p4理解它？合并就在那里令人沮丧。

我有过的想法：

使用git filter-branch删除所有提及的冲突文件。虽然缺少许多文件更改，但我会得到历史记录。在历史上大约有3000次提交，我最终会删除所有关键（繁忙）文件的历史记录。在过滤文件导入结束时，我会通过最终提交HEAD来添加丢失的文件。
转储历史记录，执行HEAD的单个p4提交（简单但悲伤）。
不要转到p4：我已经尽可能长时间地实现了这个想法。

其中没有一个真的很棒。关于如何git'gt p4 rebase'或'git p4 submit'工作的任何想法？

Answer 1

“扔掉旧历史”的选择并不像听起来那么糟糕：你可以永远保持你的git repo，以防万一有人需要挖掘旧的东西。不幸的是，在svn和p4等旧式线性系统中，没有办法表示git复杂的历史观。

回顾旧历史的主要原因是'git annotate'（我假设p4有类似的工具）。如果这就是你想要的全部，那么你真正想要做的就是将所有的合并提交压缩到只有一个父项（因此它们看起来像是一次提交而不是合并）。这更像是svn和p4在他们自己的历史模型中记录的内容，其中合并看起来就像线性流中的单个提交。您可以使用git-filter-branch等来完成此操作。当然，这会丢失在子分支上发生的所有历史......但p4用户习惯于没有这些信息。

Answer 2

您是否检查过“裁缝”工具？它是用于同步不同VCS的构建：es。它应该有Perforce支持。

作为旁注，我的第一反应是严肃质疑这个决定，但我想你已经做到了。

Answer 3

你看过 Perforce Fusion 吗？

大约在 7 到 8 年前，我遇到过类似的问题，我们基本上将所有高级开发人员召集在一起，并告诉推动这个想法的经理他已经放弃了。

也就是说 - https://www.perforce.com/perforce/r15.3/manuals/git-fusion/

Answer 4

我认为您应该尝试使用Tortoise SVN然后考虑单个分支更新的Hg，或者您可以说迁移。确保克隆的所有转储都是安全的。祝你好运！

从git迁移到Perforce

4 个答案: