This is only one of a number of differences in the underlying ontologies of mercurial and git. Another is branches: git repositories have no concept of a "branch" in the mercurial sense, what git calls a "branch" is more like an hg bookmark. I'm not sure how a tool like this can deal with such things without either disabling some hg functionality or adding metadata to keep track of the hg stuff that git doesn't track.

The branch is a wad of metadata included in (attached to?) the commit. It'll somehow have to roundtrip the various metadata.

I doubt it'll ever be 100% complete, but you should be able to get quite a ways. Certainly far enough to make it work using github as your repo of record (and as someone who regularly submits github PRs via hg-git, I have evidence that it can work.)

I don’t think hg has the concept of unnamed heads in any sort of acceptable manner. You can have 2 heads with the same branch name, which I suppose is called an “unnamed head” but your team will berate you if you force push an unnamed head. (You can’t push an unnamed head without force. Using force almost always means you shouldn’t do whatever you’re doing) when git encourages using ‘force’ I say a silent prayer

In a way, this is backwards. hg is and has always been totally fine with multiple unnamed heads; git is the one that insists that topological heads have some ref pointing at them.

But I agree with your basic point. Unnamed heads in git and unnamed heads in hg are not treated the same, and could be easy for tools to mix up. (I hadn't realized that this was even possible in git??)