使用hg convert --filemap添加rename规则导致转换失败的问题排查

这是Bug吗？ #

没错，你遇到的这个问题确实是Mercurial的convert扩展的已知兼容性问题，和你的操作无关。核心问题出在：当源仓库里有手动解决过冲突的合并提交时，convert扩展在应用filemap里的rename规则时，没法正确映射两个父节点的修改路径——它会误以为目标仓库的两个父节点没法自动合并，于是就抛出了那个unable to convert merge commit since target parents do not merge cleanly的错误。哪怕是你写的那种虚拟rename规则（比如rename foo bar而foo根本不存在），也会干扰它的路径计算逻辑，尤其是合并提交这种复杂场景。

你操作错了吗？ #

完全没有！从你给出的复现步骤来看，整个流程都是标准操作：创建文件提交、分支修改、手动解决冲突合并、用带rename的filemap执行转换。每一步都没问题，锅在工具本身。

可以怎么解决？ #

给你几个实用的方案：

1. 先转换仓库，再单独做重命名 #

绕开filemap里的rename规则，先把源仓库完整转过去，之后在目标仓库里手动执行重命名操作：

# 先用不含rename的filemap完成转换
hg convert --filemap my-filemap-no-rename.txt source-repo target-repo
# 进入新仓库
cd target-repo
# 执行重命名
hg rename foo bar
# 提交这个重命名变更
hg commit -m "Rename foo to bar across entire history"

这个方案最稳妥，也不需要修改源仓库的历史。

2. 重新生成无手动冲突的合并提交（如果可行） #

如果你还能修改源仓库的历史，可以重新做合并：尽量让两个分支的修改能自动合并（比如调整分支上的修改，避免冲突），再用带rename的filemap尝试转换。不过这个方案只适合源仓库还在你的可控范围内的情况。

3. 用reposurgeon工具处理 #

reposurgeon是专门用来修改版本仓库历史的工具，它对路径重命名和合并提交的处理比原生的convert灵活得多。你可以用它先给源仓库的历史批量加上重命名，再导出成新的Mercurial仓库。

内容的提问来源于stack exchange，提问作者Dinu