catskul
commented
5 years ago I've filed a bug with hg-git here: https://bitbucket.org/durin42/hg-git/issues/280/use-of-extra-header-as-storage-of-metadata
I believe I've determined that it is indeed hg-git's use of extra metadata that is causing this. The idea solution would be to have it fixed on their side.
AFAICT the only way to offer compatibility from git-remote-hg (for any repo created with an unfixed version of hg-git) would be to try and match their metadata. At first inspection this seems like a messy and undesirable solution.
While the optimal solution is to have it fixed on the hg-git side, some users will still have a solution for repositories that cannot be rebuilt from scratch so I'm going to see if I can come up with a potential work around solution.
The semi-offical hg-git extension for mecurial provides an analigous solution to bridge git to hg. As such when converting mercurial repositories to git one may use hg-git or git-remote-hg to do the transformation.
Unfortunately despite the history appearing to be identical, some subtle difference appears to be creating a difference in hash.
As a result, difficult merge problems occur in the transition where native git users cannot merge or rebase with the legacy hg servers using git-remote-hg without causing a rift in the space-time continuum because git believes the histories are different.
I propose finding the difference and offering a compatibility mode. The same change could/should be made on the hg-git side, and I'll propose it there as well.
When/if I figure out the issue causing the divergence I'll update this ticket.