linux - 使用 Google 的 'repo' 工具进行多次 checkout 的共享对象存储？

Question

在我的组织中，我们使用 Google 的 repo 工具来维护分布在约 200 个 git 存储库中的代码库。由于编译和测试运行速度非常慢，我通常在我的 Linux 机器上 check out 该源代码树(例如，一个当前正在编译，另一个我准备下一次提交)。

这些 checkout 的源代码树每个消耗大约 7.5GB，其中 5.5GB 是 git 对象存储(通常在每个存储库的 .git 文件夹中，但 repo将其重定向到源代码树根目录中的 .repo 文件夹)，实际工作副本只有 2GB。所以我的问题是:我怎样才能(轻松地)让这些不同的 checkout 共享它们的对象存储，以便对象存储中的每个 git 对象只在我的硬盘上存储一次？

我知道这可以通过对单个 git 存储库进行多次 checkout 来实现，但我不确定存储库对对象存储的重定向可能会如何影响这些方法。简单地用硬链接(hard link)替换重复文件可能行不通，因为 git 将大多数对象存储在共享包文件中，并且即使其中的对象是相同的，不同 checkout 之间的对象也不相同。

Answer 1

我正在做的是:

1. 运行 repo init初始化新的 repo。

2. 内部 .repo并创建两个名为 project-objects 的符号链接(symbolic link)和 projects指向现有 .repo 中的同名目录.

3. 然后上一层然后repo sync .

repo到目前为止喜欢这个；如果我遇到任何问题，我会更新这个答案。

几乎可以肯定，我们希望避免并发运行 repo以这种方式共享对象的 repo 树中的操作，因为这些操作反过来可以在同一个 git 中发出并发操作 repo 。

如果这是要走的路，下一步显然是将全局对象存储放在任何 .repo 之外。一些特殊位置的目录，并通过符号链接(symbolic link)将它们全部指向那里。

它看起来像 --mirror和 --reference repo 的参数应该能达到类似的效果，但我找不到任何关于它们的文档来解释它们到底做了什么和 repo help init缺乏细节。看起来好像 --mirror应该 pull 下 repo 的本地镜像(不是客户端 checkout ，而是一个特殊的镜像对象)，然后用 --reference 引用它检查客户端 repo 时的参数。

符号链接(symbolic link)的优点是我无需阅读未记录的 Python 源代码即可理解它们在做什么。