Git 存储库唯一 ID
我需要查明提交是否属于特定的 git 存储库。
这个想法是为我需要测试的每个存储库生成一些唯一的 ID。 然后我可以将此唯一 id 与根据测试提交计算出的 id 进行比较。
例如,采用初始更改集的 SHA。它能唯一标识存储库吗?
I need to find out if a commit belongs to a particular git repository.
The idea is to generate some unique id for every repository I need to test.
Then I can compare this unique id to the id, calculated from tested commit.
For example take an SHA of initial change set. Can it uniqely identify the repository?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
SHA1 密钥用于识别内容(blob 或树的内容),而不是存储库。
如果每个存储库的内容不同,那么它的历史就没有共同的祖先,所以我认为基于更改集的解决方案不起作用。
也许(未经测试)您可以通过 git 笔记。
例如,请参阅 GitHub deploy-notes,它使用此机制来跟踪部署。
The SHA1 key is about identifying the content (of a blob, or of a tree), not about a repository.
If the content differ from repo to repo, then its history has no common ancestor, so I don't think a change-set-based solution will work.
Maybe (not tested) you could add some marker (without having to change all the SHA1) through git notes.
See for instance GitHub deploy-notes which uses this mechanism to track deployments.
(从评论中移出)
如果您的存储库中没有特定提交的父级,则这是不可能的(在这种情况下,您可以简单地回答这个问题)。虽然提交保存了对父级的引用并以这种方式维护整个树的完整性,但如果没有该提交,则无法仅根据哈希重建提交,因此您无法找到该父级的父级,依此类推,直到您会找到实际上位于您的存储库中的父级。
(moved from comment)
That's not possible if you don't have the parent of the particular commit already in your repository (in which case you can trivially answer the question). While the commit holds a reference to the parent and maintains the whole tree's integrity that way, you cannot reconstruct a commit just from the hash if you don't have that commit, so you can't find out that parent's parent and so on until you find a parent which actually is within your repository.
您可以使用 git filter-branch 来搜索您要查找的提交。
初始提交的哈希值不会为您提供有关存储库本身的太多信息。没有办法唯一地标识存储库。
You can use
git filter-branch
to search for the commit you are looking for.A hash of the initial commit does not give you much info about the repository itself. There's no way to uniquely identify a repository.
在 Rietveld 中,当人们想要查找针对其存储库的评论时,我们不能强迫每个人都使用“git Notes”,因此我们将使用 git rev-list --parents HEAD 输出中的最后一个哈希值代码>.
In Rietveld we can not force everybody to use 'git notes' when people want to find reviews made against their repositories, so we are going to use the last hash from the output of
git rev-list --parents HEAD
.与 Mercurial 相比,其中检查
mercurial/treediscovery.py
(Mercurial 存储库标识):base
变量存储两个存储库的最后公共部分。Git 在获取/推送时发出
警告:没有常见提交
时也有相同的假设。我只是没有 grep Git 源代码,这需要时间。通过给出 Mercurial 推/拉检查的想法,我们可以假设存储库是相关的(如果它们具有共同的根)。对于 Mercurial 来说,这意味着来自命令的哈希值:
对于两个存储库都必须具有非空感叹词。
您可能不会通过精心制作存储库来欺骗根检查,因为构建两个存储库看起来像这样(具有共同部分但根不同):
不可能,因为这意味着您反转 SHA-256,因为每个后续哈希都取决于先前的值。对于 Mercurial 和 Git 来说都是如此。
在 Git 中查看根的相应命令是:
您可以尝试一下:
注意 Git 允许部分签出。我没有检查此案例的
--max-parents=0
。Compare with Mercurial, where is checks
mercurial/treediscovery.py
(Mercurial repository identification):base
variable store last common parts of two repositories.Git have same assumptions when emit
warning: no common commits
on fetch/push. I just didn't grep Git sources, that require time.By giving this idea of Mercurial push/pull checks we may assume that repositories are related if they have common roots. For mercurial this means that hashes from command:
for both repositories must have non-empty interjection.
You may not trick roots checking by carefully crafting repositories because building two repositories looks like these (with common parts but different roots):
impossible because that mean you reverse SHA-256 as each subsequent hash depends on previous values. That is true both for Mercurial and Git.
Corresponding command to see roots in Git is:
You can toy yourself with:
NOTE Git allow partial checkout. I didn't check this case for
--max-parents=0
.当我对存储库有写访问权限时,我发现生成一个随机 uuid 很有用,我将其存储在
.gituuid
文件中,该文件也已提交:这在全局范围内解决了如何唯一标识存储库的问题,但这个答案仅在您具有写入权限时才相关。
注意:我还有一些其他脚本可以跟踪这些 git uuid,并允许我找到文件系统上关联的存储库的位置。但这超出了范围。
When I have a write access on a repo, I find useful to generate a random uuid that I will store inside a
.gituuid
file, which is also commited:This globally solve how to uniquely identify a repo, but this answer is only relevant if you have write permissions.
Note: I've some other scripts that tracks thoses git uuids and allow me to locate where are the associated repo on my file system. But this is out of scope.