如何让Mercurial识别Git文件重命名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是一款让MercurialMercurial / Hg与Git双向桥接的插件装上它你就能用hg push/hg pull直接和 Git 仓库协作。但有一个隐形坑——重命名检测默认是关闭的从 Git 拉取提交后一次git mv在 Mercurial 里会变成删除旧文件 新增新文件文件历史就此断裂。本文带你用 3 个核心配置项完成Mercurial 文件重命名检测调优让重命名、拷贝在hg log中完整呈现。为什么 Mercurial 默认看不见Git 重命名Git 的提交对象里其实不存储重命名信息——git mv在提交时只是一次普通的删旧 加新重命名是git diff显示时靠内容相似度临时算出来的。而 Mercurial 会把重命名作为提交的一等公民记录下来。所以 hg-git 在把 Git 提交翻译成 Mercurial 变更集时需要自己做一次相似度计算。为了避免性能意外大仓库全量比对非常慢这个检测默认关闭similarity 0。 换句话说不是识别不了而是需要你先在 hgrc 里打开开关。检测器在 hggit/git_handler.py 中构建完整文档见 README.md。重命名检测调优hg-git 三大配置项所有配置都写在 hgrc仓库级.hg/hgrc或用户级~/.hgrc的[git]段下。1️⃣ git.similarity重命名相似度阈值核心开关取值0100表示两个文件一对删除/新增内容相同多少百分比才算重命名。默认0即关闭检测。取值效果0关闭检测默认最安全50宽松改动超过一半也认作重命名适合小幅重构90保守文件需保持 90% 以上相同误判极少100最严格内容完全一致才算重命名[git] similarity 50 官方测试 tests/test-renames.t 用的就是similarity 50能正确识别alpha → beta的重命名和beta → gamma的拷贝。2️⃣ git.renamelimit单次检测的文件数上限重命名检测的复杂度是 O(N²)——一次提交改动 1000 个文件比对量就是百万级。git.renamelimit规定当一次提交修改的文件数超过该值时直接跳过检测。默认400与 Git 的diff.renameLimit保持一致小仓库保持默认即可不要盲目调大否则hg pull会明显变慢。3️⃣ git.findcopiesharder深度拷贝检测谨慎开启开启后未修改的旧文件也能作为拷贝的来源类似git diff --find-copies-harder。代价是大项目上非常昂贵默认False除非你明确需要找回从老文件复制出来的历史否则不建议开。[git] similarity 50 renamelimit 400 # findcopiesharder True ; 大项目慎用三步快速启用重命名检测配置步骤第 1 步安装 hg-git 插件git clone https://gitcode.com/gh_mirrors/hg/hg-git在~/.hgrc中注册扩展路径按实际克隆位置填写[extensions] hggit /path/to/hg-git/hggit第 2 步在[git]段添加重命名检测配置[git] similarity 50第 3 步重新拉取并验证对已有仓库删除本地 Git 缓存后重新导入即可看到效果hg gclear hg pull提示重命名检测发生在Git → Mercurial 导入方向。反方向hg → git则相反——Mercurial 提交中的重命名会被写成HG:rename/HG:rename-source元数据存入 Git 提交保证双向转换无损。如何选择合理的 similarity 值调参思路很简单值越大越保守越小越宽松。日常协作仓库推荐50能覆盖绝大多数改了名字顺手改几行的场景重构频繁、文件大量搬家的仓库可降到40接受少量误判对精确性要求高如生成 changelog设90以上宁可漏报不误报⚠️ 改完配置后已导入的历史提交不会自动重新识别——如需重建历史需hg gclear后重新导入。如何验证重命名检测已生效拉取后用hg log -p查看提交详情✅ 识别成功diff 中出现rename from alpha/rename to beta拷贝为copy from/copy to❌ 未识别同一提交里旧文件显示deleted file新文件显示new file。提交元数据里还应带有hg-git-rename-sourcegit标记表明该提交的重命名信息由 Git 侧推断而来。常见问题FAQQ1为什么不直接跟随 Git 默认的 50%Git 的重命名是显示期计算不影响数据hg-git 的重命名会写入 Mercurial 历史属于数据级决策所以默认关闭把选择权交给你。Q2开启后 hg pull 变慢了调低renamelimit如200或临时把similarity设回0。Q3在 Mercurial 里hg mv的文件名会被 Git 侧识别吗会被记录。hg-git 在推送时把重命名写入HG:rename元数据Git 用户通过工具读取这些标记即可获得准确的文件历史。小结配置项默认值一句话建议git.similarity0关闭设50快速启用重命名检测git.renamelimit400保持默认防止大提交卡顿git.findcopiesharderFalse大项目不要开只需在 hgrc 中加一行similarity 50Mercurial 就能看懂Git 提交里的文件重命名与拷贝hg log的历史视图从此完整清晰。更多配置作者映射、分支后缀等可继续查阅 README.md 的 Configuration 章节。【免费下载链接】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），仅供参考