检查两个 git 存储库是否相关答案

【问题标题】：Check if two git repositories are related检查两个 git 存储库是否相关
【发布时间】：2020-02-05 18:05:51
【问题描述】：

给定两个裸露的非浅层 git 存储库，我如何以编程方式（通过 Python 脚本）检查它们是否相关？存储库可能具有完全不同的分支，或者指向不同历史的同名分支。如果我只是简单地进行推送（可能使用--dry-run），即使两个存储库没有共同点，git 也会创建一个新分支。如果我反向“拉”，git会打印“拒绝合并不相关的历史”，但--dry-run，并不表示任何错误。

我的想法是获取两个存储库中的 all 提交哈希列表（包括所有分支和没有分支头的“丢失”提交）并检查它们是否包含公共子集。但是，我找不到真正找到所有哈希的方法。

我需要将此作为脚本的一部分，该脚本自动收集对许多存储库所做的更改并将它们合并到这些存储库的旧版本中，但要确保不会意外推送到错误的、可能同名但不相关的存储库.

【问题讨论】：

你能通过抓取git log的输出得到所有的提交哈希吗？
不，因为这不包括没有头的历史（分支名称）......
“不，因为这不包括没有头的历史（分支名称）”。好吧，至少这个特定方面可能应该首先单独解决，对吧？在 Git 中，无法访问的对象作为垃圾收集的一部分被删除。如果那里有什么有用的东西，应该首先“保存”（例如，使用git fsck 找到它们并为它们分配一些分支名称）。
我不能在不分配名称的情况下获取无法访问的对象的哈希吗？此外，一个存储库可能包含一个实际引用某些丢失提交的头部，因此在推送之前分配一个名称将是多余的。
当然可以。 git fsck 获取无法访问的对象列表。只是在没有分配任何 ref 的情况下很难使用它们，因为几乎每个 git 命令都希望它们是可访问的。此外，您在 repo 上运行的任何“瓷器”命令都可以随时调用 GC 并杀死这些无法访问的对象。

标签： git revision-history

【解决方案1】：

获取 repo 中所有提交哈希的列表

git rev-list --all --full-history

这将报告可从任何 ref 访问的每个提交的哈希，禁用历史简化 - 这应该可靠地为您提供每个提交哈希。

（可能会“错过”悬空提交，但这些提交通常不会被推送或获取，并且可能会被任意删除，因此没有真正的理由来计算它们。）

对于您要推送到的仓库，上述内容应该没问题。对于您要从中推送的存储库，上述方法同样有效，但比较 all 的哈希值可能是浪费时间。如果您现在正在应用什么更改，并且更改有意义地适用，那么您应该能够找到可从更改中访问的提交之一。

因此，例如，如果您保持 refs 告诉您上次同步时分支的位置，那么您可以从列表中排除从这些 refs 中可访问的所有内容。（或者，如果您只是想使特定分支保持同步，则可以省略 --all 而只省略 rev-list 每个分支。）

【讨论】：

完美，谢谢！这正是我一直在寻找的。在这种情况下，效率不是问题，所以没关系。