hg-git | git bridge , pushed to directly from the hg-git plugin | Plugin library

Some years ago, Mercurial | TortoiseHG could exchange data bidirectionally easy with at least 2 Big Brothers:

• Subversion, using HGSubversion
• Git, using HG-Git

Current (6.0 versions of family) state - the ordinary users have none:

• hg-subversion is broken (extension can't be loaded), bundled with THG (Mercurial ???) extension not updated since 2019 hgsubversion: 6a6ce9d9da35 2019-04-19 (extraction from my TortoiseHg\extension-versions.txt), external SVN-bindings exist only for Python 2.7 (while py3-movement inside Mercurial is live and active)
• hg-git got some big troubles, starting from THG 4.9 (manual patching of library.zip was required), on 6 version the situation has gotten better (no patching), but still unsatisfactory for the common user - installing Python 2.7 (for single-user) and using pip isn't The Right Way (tm)

Are there any comments, additions, clarifications, recommendations on how to do it (if what I am doing is wrong)?

Addition after some testing: special verson tortoisehg-6.0hggit-x64.msi from Matt Harbison at least allow using hg-git with ssh-transport (not http yet) and can be recommended for every-day usage by ordinary user.

This is currently a purely theoretical question (related to this one), but let me first give the background. Whenever you run hg gexport the initial hash will vary from invocation to invocation. This is similar to when you run git init or hg init. However, since the Mercurial and Git commits correspond to each other and build on previous hashes, there should be some way to start over from a minimal common initial state (or minimal state on the Git side, for example).

Suppose I have used hg-git in the past and now I am trying to sync again between my Mercurial and my Git states, but without (or very little of) the original .git directory from the hg gexport. What I do have, though, are the two metadata files: git-mapfile and git-tags.

There is an old Git mirror, which is sort of "behind" and the Mercurial repo which is up-to-date.

Then I configure the Mercurial repo for hg-git like so (.hg/hgrc):

I wanted to install the hg-git extension with python pip but I'm not sure if I should use pip (Python2) or pip3 (Python3).

hg version gives this:

I'm trying to clone a git repository with mercurial and hg-git, but an AttributeError keeps coming up. When I run hg clone git://github.com/michaelfm1211/simpleserve, the output I get is this:

I'm currently dealing with the fallout from BitBucket dropping HG support. We're going to be giving hg-git a try because, while my preference is self-hosting, my boss isn't quite mad enough at Atlassian to move away from BB yet. Taking this opportunity to clean up our existing HG repo before the conversion to GIT. Have used hg convert to remove some accidentally committed binaries to reduce size, etc.

One thing I've noticed is that we've got about two dozen old branches that are technically "open", but have been merged into default (no closing commit, but they're months to years old). Is there any way I can use a tool like hg histedit or during the hg convert to go back and specifically mark old branch heads with --close-branch?

Looking through docs I can find things about editing files, editing the contents of commits, or modifying commit messages, but nothing I can find mentions meta-data around whether a commit is "closed". I know this is just a flag on a given commit, but I don't know how to retroactively add it via any HG extension.

Edit: Just to add a bit more clarity, I recognise I can just update to each of these old branches & add a new commit that just closes the branch. There'll be a lot of dangling-looking, closed heads, but that'd work fine enough. However, I also then have to give each of them a bookmark in HG as well, or these additional "closing" commits are lost in the hg-git conversion. I'd rather avoid having to add ~30 additional branches to the git branch-list, just to have them show up as closed properly in HG without having to use revsets.

What I want to do isn't "essential" in the grand-scheme of the repo, but I'd be surprised if editing a commit's metadata to say --close-branch were impossible.