Other than noticing that old commit hashes cannot be used on Heptapod (i.e. no direct link translations), no significant updates. The FAQ about progress & stuff applies here as well.
Edit: looked further into the Bitbucket - Heptapod link translation issue for commits. Heptapod uses internally a Git repository, as a temporary implementation detail (they intend to get rid of it eventually, but that will probably take some months or years). I've tried to replicate their Git mirroring process using their fork of
hg-git, and I can get consistent Git - Hg mappings until commit 2c7a27c / b08b345ea3f3fb5dc11a0f6ffb4603b07063761a. The next commit, b8083a2 / cea71a6a628f66b722725387bb9c5c4794b0df16 on Heptapod, shows up as ae85588aeb12efb0895b9c41efd18e5d3c747de6 in my local Git copy.
I've looked at their sources (Heptapod itself is open source) and found the hash translation code in
hg_git_repository.rb. They use a file named "git-mapfile", apparently generated by hg-git, which stores the mapping between git and hg commit hashes.
Currently, they don't seem to be able to look up anything on the web interface using the Mercurial commit hash (grep their sources for "sha_from_hgsha"), so in order to fix our Bitbucket commit links throughout the forum and documentation, we need to pick one of those:
- fix them manually (there are probably hundreds, not going to do that)
- ask Heptapod admins to implement this functionality for us (feature request)
- hack Heptapod source code to implement it ourselves, according to their coding standards, and submit a PR (it
has to be accepted by them, a local fork won't be enough)
- ask Heptapod admins for their copy of git-mapfile for our repo
- write a crawler that browses our repo on Heptapod's web interface and rebuild git-mapfile from there
According to the first joke from
here, the problem is solved - you may consider I'm the mathematician
