从最开始接触 DVCS 到现在有10多年了,这也是在 Bitbucket 上安家的10年,当初选择它是因为只有它支持免费的私有库。最初 Bitbucket 只支持 Mercurial (我更愿意用Hg这个简单的名字,所以以下都写 Hg 算了),所以我也用了 Hg 十年。后来 Atlassian 收购了 Bitbucket 之后,开始支持 Git,然后我又开始用 Git。于是每年都有那么比较闲的几天,就开始纠结:“最近工作不多,要不要把 Hg 的库转成 Git 库啊?" ”Hg 也不错啊,使用简单方便,先用着吧“。于是,眼看着 Hg 的库越来越大,越来越大,甚至于有一次 Bitbucket 来邮件说我的库体积太大了:)。现在,终于不用纠结了,因为 Bitbucket (准确得说,应该说是 Atlanssian) 帮我做了这个“痛苦”的决定,Bitbucket 在2020年6月结束对 Hg 的支持,到时候直接删除所有基于 Hg 的库。更让人”痛苦“的是,他们不提供任何转换工具,是直接删除!你要做的就是在 dealine 之前,为你的库找一个好的“归宿”。我想了想,大概有三个选择:
对于 Latin 语系的码农来说(我指的是免费用户),选项3是最简单的,因为 Github 可以直接导入 Bitbucket 的 Hg 库,而且 Github 也有免费的私有库,所以直接滚到 Github 最麻利。但是对于我来说,就没有那么容易了。首先,1肯定不会是我的选项,Bitbucket 都用了 'Sunsetting‘ 这个悲凉的字眼,想必 Hg 的未来也是越来越暗淡。3看似比2简单,但是有个编码的坑,Hg 的设计原则决定了它不会对你的提交内容进行任何改变。在 Windows 上的 GBK 编码的文件名,提交信息,在提交到服务器上,仍然是原汁原味的 BGK,不会变成 UTF-8。而 Github 在导入的时候,貌似不关心编码,也是原汁原味得导入。结果是 Github 导入后,所有的中文提交信息都是乱码,所有的中文文件名也是乱码。在 pull 到本地时,还要把 Git 的编码方式改成 GB18030 或者 GB2312 (SourceTree) 里有选项,否则你 checkout 的东西就成了乱码。
幸运的是,Bitbucket 还是给指了条路,可以用 fast-export 将 Hg 库导出到 Git 库。fast-export 的好处是有个 "-e” switch 可以指定原库的编码方式,这样转换成的 Git 库在 Windows 上就可以不用将编码更改成 GBK 了。步骤是:
说复杂也不复杂,其实复杂不复杂取决于有多少库要转换。现在我的状态是痛并快乐着,快乐是因为,我以后不用再纠结了,电脑里终于要由 Git 一桶天下了。