hg-fast-export.py fails due to missing hg2git module

[eric-s-raymond]

I grabbed a copy of hg-fast-export.py hoping that. run in a Mercurial repository, it would ship a fast-import stream to stdout.

Instead it fauiiled with this message:

Traceback (most recent call last):
  File "/home/esr/bin/hg-fast-export.py", line 6, in <module>
    from hg2git import setup_repo,fixup_user,get_branch,get_changeset
ModuleNotFoundError: No module named 'hg2git'

I see no documentation about how to meet this depedency. I don't even see any documentation of what this Python script is supposed to do. Please fix these problems.

[frej]

I grabbed a copy of hg-fast-export.py

Are you running hg-fast-export.py by itself, from the report it's not clear if that's your intention or if this is an error message you get when running hg-fast-export.sh?

The only supported external interface to the Mercurial to Git conversion is hg-fast-export.sh as shown in the first example in the usage section of the readme.

I see no documentation about how to meet this depedency. I don't even see any documentation of what this Python script is supposed to do. Please fix these problems.

hg-fast-export.py is an internal component, if you feel it worthwhile to document its interface, patches are welcome.

edit: BTW, the hg2git module is in the repo.

[eric-s-raymond]

I was indeed running hg-fast-export.py by itself. As I said in my original bug report, "hoping that. run in a Mercurial repository, it would ship a fast-import stream to stdout." If it can't do that, this issue turns into a feature request.

Explanation: I am the maintainer of reposurgeon, a tool for surgery on and conversion of repository histories. That code wants to use plugins that emit fast-import streams to ingst repositories. For example, it uses cvs-fast-export (which I also maintain) to import CVS repositories. You can read more about it here:

http://www.catb.org/~esr/reposurgeon/repository-editing.html

It has support for lots of systems besides git and hg, inclusing bzr/brz, CVS, Subversion, src, fossil, and darcs. It uses an extended Git-like object model internally.

In an ideal world, hg would have its own built-in fast-export command. Since it doesn't, I periodically do searches looking for capable, well-documented hg fast-export utilities. Yours has lots of competition, all of them poorly documented and with unknown failure modes. I have not found one I can comfortably recommend.

"Patches are welcome" is not a confidence-building answer - I need to be able to rely on an export tool, not have to fix and document it myself (I already did that once with cvs-fast-export, that was enough times). I want something that its maintainer is willing to stand behind and document properly, so I can focus on reposurgeon's part of the problem.

By "document properly" I mean it needs to describe things like how hg's slightly odd tagging semantics maps to git objects, and what happens to things like bookmarks and multiple heads. I need its failure modes and warnings to be described so so I can point my reposurgeon users at that description.

Eventually somebody will step up and do this right. Maybe you?

[frej]

I was indeed running hg-fast-export.py by itself.

I just wanted to be 100% sure before accusing you of doing unsupported things, additionally the recent removal of Python 2.7 support could have messed something up.

Explanation: I am the maintainer of reposurgeon

Yes, I remember. We had an email exchange in May 2020, you wanted a tool that spits out a fast-import stream. I answered: As for dumping the stream to stdout there is currently no way to do that, but I would not reject a patch adding support, as it could be useful for debugging. Figuring out the redirection setup around the exec on line 173 in hg-fast-export.sh is probably the hardest part of writing that patch.

The same applies today, but since 2020 Chris J Billington (@chrisjbillington) has created a tool that massages the Hg-repo in order to make it compatible with Git's world model. Hg-fast-export has also acquired a plugin to deal with unnamed heads.

"Patches are welcome" is not a confidence-building answer - I need to be able to rely on an export tool, not have to fix and document it myself (I already did that once with cvs-fast-export, that was enough times). I want something that its maintainer is willing to stand behind and document properly, so I can focus on reposurgeon's part of the problem.

I have very little time to dedicate to hg-fast-export, the time I have, I spend on maintaining it so it correctly performs its core function: converting Hg-repos to Git. I'm willing to accept patches for additional features if they do not risk to greatly increase the maintenance effort. My opinion is unchanged since 2020, I would not reject a patch which allows the raw fast-import stream to be dumped.