初始克隆后扩展`git-p4` clientspec

Question

执行git-p4 clone --use-clientspec完之后,我想在clientspec中添加一个额外的条目,并将添加的条目的当前状态导入到我的Git存储库中.

在我扩展了clientspec之后,a git-p4 rebase什么也没做(可能是因为自上次提交的更改以来没有新的相关更改列表,我所做的就是更新clientspec)

我试过做了git-p4 sync --use-client-spec,但是抱怨快速导入失败了,因为新的提示不包含我的初始提交.

有没有办法扩展客户端规范,而无需git-p4 clone从头开始新的Git存储库？

Answer 1

截至撰写本文时，我找不到git-p4直接从 Perforce clientspec 导入其他路径的方法。然而，我相信我已经设计了一种手动执行此操作并尊重git-p4它的方法。

免责声明：对于以下步骤可能造成的任何损害，我不承担任何责任。首先备份你的.git树可能是个好主意。

这个想法

正如您所说，仅添加 Perforce clientspec 的路径并执行git p4 rebase初始操作不会执行任何操作。但是，我注意到，git p4 rebase在 Perforce 中修改文件后，如果新路径位于 的列表中，则会从该路径添加git-p4文件depot-paths。（depot-paths是提供给 的仓库路径的初始列表git p4 clone。）因此您需要：

1. 获取 Git 存储库新路径的初始副本。
2. 欺骗人们git-p4相信它是自己添加了最初的副本。
3. 将git-p4新路径包含在其depot-paths列表中。

因此，您可以从 Perforce 同步文件的副本，确保它们与已从 Perforce 导入的文件一致，然后您可以将它们显式添加到 Git 存储库。

git-p4depot-paths显然，除了 Git 提交消息之外，它不会存储其列表或最后导入的 Perforce 更改编号，因此您可以git-p4通过在自己的提交消息中复制其元数据来欺骗。

最后，您可以移动p4/master（和p4/HEAD，它是 的别名p4/master）指向您的新提交，以便将来的git p4 rebase命令将该提交视为从 Perforce 导入的内容。

一步步

1. 查看对应的提交p4/master。确保您没有任何分阶段或未分阶段的更改。如果你这样做的话，把它们藏起来。

2. 将新路径添加到 所使用的 Perforce clientspec git-p4。在下面的步骤中，我将其称为//depot/new/path/。

3. 运行git log以查看上次导入的 Perforce 更改的提交消息。它将有一条看起来像这样的行：

   [git-p4: depot-paths = "//depot/tree/": change = 12345]

   记下 Perforce 更改编号。

4. 在您的 Perforce 客户端中，将您添加的路径同步到该更改编号。例如：p4 sync //depot/new/path/...@12345

5. 将这些新同步的文件从 Perforce 客户端递归复制到 Git 存储库中的相应位置。（如果有符号链接，这里可能需要小心。）

6. git add在 Git 存储库中的新路径上运行。

7. 跑步git commit。您可以在提交消息中说出您想要的任何内容（例如“Initial import of //depot/new/path/ from CLN 12345”）。但是，在消息末尾，您必须复制git-p4之前观察到的元数据行：

   [git-p4: depot-paths = "//depot/tree/": change = 12345]

   如果//depot/new/path/不是 的子目录//depot/tree，则必须修改depot-paths以添加新路径：

   [git-p4: depot-paths = "//depot/new/path/,//depot/tree/": change = 12345]

   该depot-paths列表必须按 ASCII 值排序（即//depot/foo-bar/应该在 之前//depot/foo/bar/）。

8. 再次运行git log。确认git-p4提交消息中的行看起来像来自导入的 Perforce 更改的行。记下您提交的 SHA1 哈希值。

9. 导航到 Git 存储库的根目录。编辑.git/refs/remotes/p4/master。删除列出的旧 SHA1 哈希值并将其替换为您提交的 SHA1 哈希值。（如果.git/refs/remotes/p4/master不存在，请检查.git/packed-refs并更新相应的行。）

现在，您的 Git 存储库包含来自更改 12345 的文件副本//depot/new/path/，并且它应该会从未来的 Perforce 更改中获取这些文件的任何更改。

其他一些值得注意的事情

• 显然，只有在提交导入这些文件之后，新路径才会存在于 Git 存储库中，因此git bisect如果它跨越该边界并涉及这些文件，则不会有用。

• 由于修改后的文件如果包含在您的 Perforce clientspec 中（并且包含在git-p4s中depot-paths），则会自动添加，因此在某些情况下您可能可以避免所有这些工作。例如，如果您事先知道有人将向 Perforce 仓库添加一个新目录，并且该目录已包含在您的depot-paths但不包含在您的 clientspec 中，则您可以抢先将其添加到您的 Perforce clientspec 中。然后，在将新路径实际添加到 Perforce 后，您应该能够自动获取该新路径。

• 或者，您可以将新路径添加到 Perforce 客户端规范，然后提交涉及该路径中所有文件的 Perforce 更改。然而，我不建议这样做，因为这可能会对其他人造成干扰（想象一下如果其他人都这样做的话）。我提及它只是为了完整性。