我需要能够唯一标识 Mercurial 存储库，并将该标识符放置在克隆时包含的文件中。如果我可以将标识符放在 .hg 文件夹中的文件中，这比简单地将普通文件添加到 repo 更好。
我知道，我可以从提交的第一个更改中获得一个几乎确定的标识符。我知道hgrc文件不能用来存储标识符，因为它没有被克隆。
所以，我的问题是：.hg 文件夹中是否有另一个文件可以用来放置标识符？谢谢。
【问题讨论】：
标签： mercurial
从第一次阅读开始，听起来您希望能够确保存储库的克隆是正确存储库的克隆，而不是某个替身冒名顶替者。但是，如果您正在考虑使用的身份信息与其他所有内容都被克隆，那么冒名顶替者仍然可以通过此测试。您需要将该标识符分开，以便可以将其与克隆中的信息进行比较。
无论这是否是您的目的，.hg 中的任何克隆文件您都可能不想编辑。您必须在 .hg 之外的 repo 的其他区域中添加要跟踪的文件。但是，您根本不需要额外的文件，因为变更集哈希不仅接近确定，而且非常确定，因此用于轻松识别存储库的信息已内置到存储库中自己。
在命令行上，您可以获取第一个变更集哈希标识符的短版或完整版：
> hg id -i -r0
89abf5502e3c
> hg log -r0 --template "{node}"
89abf5502e3c5c65e532db04d8d87141f0ac8b73
如果我对您比较 2 个标识符的愿望是正确的，以便您或其他人知道存储库的克隆是真正的克隆而不是错误的克隆，那么您将拥有相同的 changset id，以便其他人可以使用上述命令之一查看其克隆的 id 并将其与您所说的进行比较。这很像有多少具有可下载可执行文件的网站在下载链接旁边显示一个哈希标识符，以便您可以自己对文件进行哈希处理并将结果与网站上的哈希值进行比较。
编辑 关于您阐明此目的的评论：
由于您需要能够从文件中读取它，因此有几个选项：
除了创建自己的文件之外，您还可以考虑一个文件：.hgtags。
hg tag -r0 ident
...将标记第一个修订版，允许您使用 ident 作为对该变更集的引用，而不是 -r0。 Mercurial 始终使用来自最新版本的.hgtags 的标签信息，无论工作目录更新到什么变更集，但这对您的应用程序可能无关紧要。 hg tag 在.hgtags 文件中附加这样的一行，如果文件不存在则创建该文件：
a247494248c4b96a571bbd12e90eade3bf559281 ident
如果您的存储库中还没有标签文件，这是最方便的，因为它将是文件中的第一行以便于查找。您可能认为可以简单地自己编写这个文件，但是您仍然需要调用 hg 来获取变更集 ID，并在某个时候再次将其添加到跟踪然后提交：hg tag 为您完成所有这些。
如果已经有可能考虑使用标签文件，那也没关系，因为它们往往相对较短，您只需要查找以您选择的标签名称结尾的 1 行。 Mercurial 设计用于对.hgtags 的仅附加操作，但如果.hgtags 已经存在，则如果您将此标记的行作为第一行插入，一切仍然可以正常工作，因为： 1. 永远不会移动或删除标记. 2. 您将使用文件中尚未使用的标签名称。
hg的内脏通常只有 Mercurial 本身在 .hg 中更深入地触及这些文件，可以读取这些文件以获取第一个变更集的哈希值。我查看了 Mercurial 的 File Formats、Revlog 和 RevlogNG，至少对于我自己的 2 个存储库，.hg\store\00changelog.i 包含偏移量 0x20（20 字节长度）处的第一个变更集哈希。可能，至少从 Mercurial 0.9 开始，它在所有 repos 中都是相同的。 RevlogNG 还指出该文件的前 4 个字节将指示 Revlog 版本号和标志。虽然变更集 id 目前只有 20 个字节长，但它的实际字段是 32 个字节长，可能是为了将来扩展为更长的散列。
由于此选项不需要更改现有存储库，并且只涉及读取主索引的前 52-64 个字节，因此我可能会使用它。如果我在产品管理的任何存储库出现之前就在产品的早期阶段捕捉到这个要求，我会倾向于自定义文件方法，因为我可能会从存储库的开头创建并添加我自己的元数据文件.
【讨论】：
error: repository is unrelated 消息来自mercurial/treediscovery.py：
base = list(base)
if base == [nullid]:
if force:
repo.ui.warn(_("warning: repository is unrelated\n"))
else:
raise util.Abort(_("repository is unrelated"))
base 变量存储两个存储库的最后一个公共部分。通过给出推/拉检查的想法，我们可以假设存储库具有共同的根是相关的，因此从命令检查哈希：
$ hg log -r "roots(all())"
对于我不知道的原因，hg log -r 0 总是显示相同的根，但您可能会遇到 FIRST_REPO 持有 SECOND_REPO 历史记录的情况，但显然 0 revs of SECOND_REPO 与 FIRST_REPO 不同，但通过 Mercurial 检查。
您可能不会通过精心构建存储库来欺骗根检查，因为构建两个存储库看起来像这样（具有共同的部分但不同的根）：
0 <--- SHA-256-XXX <--- SHA-256-YYY <--- SHA-256-ZZZ
0 <--- SHA-256-YYY <--- SHA-256-ZZZ
不可能，因为这意味着您反转 SHA-256，因为每个后续哈希都取决于先前的值。