git - 初始克隆后扩展 `git-p4` 客户端规范

Question

做了之后git-p4 clone --use-clientspec ，我想在 clientspec 中添加一个额外的条目，并将添加的条目的当前状态导入我的 Git 存储库。

在我扩展 clientspec 之后，一个 git-p4 rebase什么都不做(可能是因为自上次提交更改以来没有新的相关更改列表，我所做的只是更新客户端规范)

我试着做一个 git-p4 sync --use-client-spec ，但这会提示快速导入失败，因为新提示不包含我的初始提交。

有没有办法扩展客户端规范，而不必git-p4 clone从头开始一个新的 Git 存储库？

Answer 1

在撰写本文时，我找不到获取 git-p4 的方法。直接从 Perforce 客户端规范导入其他路径。但是，我相信我已经设计了一种手动执行此操作的方法并且具有 git-p4尊重它。

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

想法

正如您所说，只需添加一条到 Perforce 客户端规范的路径并执行 git p4 rebase最初什么都不做。但是，我注意到 git p4 rebase在 Perforce 中修改文件后，如果新路径在 git-p4 内，将添加来自该路径的文件的 depot-paths列表。 ( depot-paths 是提供给 git p4 clone 的仓库路径的初始列表。)因此，您需要:

获取 Git 存储库中新路径的初始副本。

欺骗git-p4相信它添加了初始副本本身。

获取git-p4在其 depot-paths 中包含新路径列表。

因此，您可以从 Perforce 同步文件的副本，确保它们与已经从 Perforce 导入的文件一致，然后您可以将它们显式添加到您的 Git 存储库中。
git-p4显然没有存储它的 depot-paths除了 Git 提交消息之外的任何地方都列出或最后导入的 Perforce 更改编号，因此您可以欺骗 git-p4通过在您自己的提交消息中复制其元数据。

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

一步步

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

将新路径添加到 git-p4 使用的 Perforce 客户端规范中.在下面的步骤中，我将其称为 //depot/new/path/ .

运行 git log查看来自您上次导入的 Perforce 更改的提交消息。它将有一行如下所示:
[git-p4: depot-paths = "//depot/tree/": change = 12345]
记下 Perforce 更改编号。

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

将这些新同步的文件从 Perforce 客户端递归复制到 Git 存储库中的相应位置。 (如果有符号链接(symbolic link)，这里可能需要注意。)

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

运行 git commit .大多数情况下，您可以在提交消息中说出您想要的任何内容(例如“从 CLN 12345 初始导入//depot/new/path/”)。但是，在消息的末尾，您必须复制 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/ 之前)。

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

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

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

其他一些注意事项

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

如果修改后的文件包含在您的 Perforce 客户端规范中(并且包含在 git-p4 的 depot-paths 中)，则会自动添加，因此在某些情况下，您可能会避免所有这些工作。例如，如果您事先知道有人要向 Perforce 软件仓库添加一个新目录，并且该目录已经包含在您的 depot-paths 中。但不是通过您的客户端规范，您可以预先将其添加到您的 Perforce 客户端规范中。然后，您应该能够在将新路径实际添加到 Perforce 后自动获取该路径。

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