hg-git核心架构剖析覆盖层与仓库子类化完整指南【免费下载链接】hg-gitmercurial to git bridge, pushed to directly from the hg-git plugin in Hg项目地址: https://gitcode.com/gh_mirrors/hg/hg-githg-git是一款连接 MercurialHg与 Git 两大版本控制系统的桥接插件让你能用一条hg push/hg pull命令直接与 Git 服务器同步。它之所以能实现无损双向转换全靠两大核心机制支撑overlay 覆盖层hggit/overlay.py与仓库子类化hggit/hgrepo.py。本文带你从零读懂它们的设计思想与协作方式。一图看懂 hg-git 的工作哲学 在深入代码前先记住三条底层原则来自 DESIGN.txt数据只以 Hg 原生格式存储Git 目录只是可丢弃的缓存随时可hg gclear清空后无损重建映射表是灵魂git-mapfile记录 Git SHA 与 Hg SHA 的一一对应保证两边节点 ID 可互相推导纯 Python 实现依赖 Dulwich 库而非 Git 命令行因此无需本机安装 Git。理解了Git 只是缓存、映射表是核心后面两个机制就都好懂了。仓库子类化机制不改源码的热补丁为什么要给仓库套壳Mercurial 的仓库对象localrepository定义了pull、push、tags等核心行为。hg-git 不想侵入式修改这些方法而是选择动态生成一个子类再悄悄替换掉仓库实例的类从而劫持关键行为。generate_repo_subclass 的运行时魔法插件在 hggit/init.py 的reposetup钩子里执行了两行关键代码klass hgrepo.generate_repo_subclass(repo.__class__) repo.__class__ klass它拿到仓库原本的类动态派生出hgrepo子类然后把实例的__class__直接指向它。这个套壳后的仓库在 hggit/hgrepo.py 中重写了四组行为重写方法作用pull/push把 Hg 的拉取/推送转发给 Git 处理器findoutgoing计算推送时本地领先远端的提交_findtags/tags把 Git 远端分支、标签伪装成 Hg 标签githandler缓存式的 Git 操作入口见下githandler通往 Git 世界的唯一入口 子类里最关键的成员是githandler属性hggit/hgrepo.py#L60-L66它按需创建一个GitHandler实例hggit/git_handler.py#L98。整个插件的导入、导出、推送、书签同步都汇聚到这个处理器里。可以说仓库子类化负责接线GitHandler 负责干活。overlay 覆盖层一个虚仓库的障眼法为什么需要覆盖层当你执行hg pull或预览 incoming 时Git 的提交已经下载下来、却还没写入 Hg。此刻 Hg 原生的 changelog / manifest 里根本没有这些提交直接展示会看不见它们。overlay 覆盖层hggit/overlay.py就是为了解决这个时间差——它构造一个看似包含这些提交、实则只读的虚拟仓库视图。overlayrepo统一视图的总入口overlayrepohggit/overlay.py#L331是覆盖层的门面。它持有两个核心结构revmap / nodemap把尚未导入的 Git 提交续编号到 Hg 现有版本号之后让它们获得临时的 rev 号changelog / manifest分别指向overlaychangelog与overlaymanifestlog提供虚拟的日志与清单。overlayrevlog伪造修订日志overlayrevloghggit/overlay.py#L253重写了parents、ancestor、node、rev等方法。它的套路是能查到的走 Git 对象查不到的就回落到真实的 Hg 仓库self.base。这种查新回旧的委托策略让虚拟提交与真实提交可以无缝地混在同一条历史里。overlaymanifest 与 overlaychangectxoverlaymanifesthggit/overlay.py#L20把 Git 的 tree 对象递归展开成路径 → blob SHA的字典模拟 Hg 的 manifest 行为overlaychangectxhggit/overlay.py#L174继承自 Hg 的changectx把一个 Git commit 包装成一次 Hg 变更集暴露description()、parents()、manifest()等接口。这两者让 Mercurial 的通用工具diff、incoming 预览在完全不知情的情况下就能操作那些尚未落库的提交。两大机制如何分工协作 它们并非平行而是各司其职使用场景触发机制说明hg pull/hg push仓库子类化子类把请求转给githandler预览 incoming未导入提交overlay 覆盖层构造overlayrepo虚拟视图SHA 互相推导git-mapfile双向映射表具体地GitHandler.getremotechangeshggit/git_handler.py#L390-L408在拉取远端后正是b overlayrepo(self, commits, refs)这一行把覆盖层接进了 Hg 的 incoming 流程——子类化负责何时调用overlay 负责看到什么。关键文件速查覆盖层实现hggit/overlay.py仓库子类工厂hggit/hgrepo.py核心处理器hggit/git_handler.pyGit 对端仓库peerhggit/gitrepo.py插件装配入口hggit/init.py设计文档DESIGN.txt总结hg-git 的优雅之处在于**不修改、只包装**仓库子类化在运行时给仓库套壳把 push/pull/tags 等关键行为劫持到 GitHandleroverlay 覆盖层用一个只读的虚拟视图填补了Git 已下载、Hg 未落库的时间差让标准 Hg 工具能直接预览这些提交两者以git-mapfile映射表为纽带共同实现 Git ↔ Hg 的无损双向同步。读懂这两个机制你就掌握了 hg-git 架构的骨架 。【免费下载链接】hg-gitmercurial to git bridge, pushed to directly from the hg-git plugin in Hg项目地址: https://gitcode.com/gh_mirrors/hg/hg-git创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考