Interest in integrating hg-git into Mercurial
raf at durin42.com
Mon Sep 9 11:03:01 EDT 2019
On Sat, Sep 07, 2019 at 05:27:30PM +0200, Joerg Sonnenberger wrote:
> On Thu, Aug 01, 2019 at 10:01:08AM -0700, Gregory Szorc wrote:
> > Is there any interest in integrating hg-git (or hg-git functionality) into
> > the Mercurial distribution as an officially supported extension?
> We've been discussing this topic a bit during the Leipzig mini-sprint
> now. I think there are three different cases for hg <-> git interaction
> to be considered:
> (1) Migrating a repository from git to hg, potentially multiple times.
> (2) Migrating a repository from hg to git, potentially multiple times.
> (3) Two-way synchronisation between hg and git.
(4) using hg as a git client
I think generally hg-git does a mediocre job of being a git client,
and the code is a pretty big tangle. I have a plan (see my RFC patch
in Phabricator, https://phab.mercurial-scm.org/D6734) for something
that's a little more ambitious but more maintainable.
> The requirements in the the first two cases are quite different from the
> third and it is useful to consider them standalone for that reason. Both
> cases are addressed by supporting the fastimport format, either reading
> or writing. I've needed a couple of changes for the hg-fastimport
> extension to work well, but it is an integral part of the NetBSD
> conversion chain right now. Changes are primarily dealing with non-UTF8
> input (something "real" git shouldn't show) and smarter blob handling
> (partially due to the way Fossil output is structured). I'm currently
> looking at the fastexport (https://repo.or.cz/w/fast-export.git) tool,
> but the performance looks mostly reasonable. One-way mirroring is much
> simpler, because it doesn't have to try to provide stable mappings for
> roundtrip consistency, the tooling just has to ensure that the mapping
> is deterministic, so that rerunning the tool will result in identical
> I believe having fastimport support in hgext would be a win,
> without the need for vendoring dulwich etc.
+1 - much as I dislike the format, fastimport streams do seem to have
some reasonable portability. I'd take a fastimport series pretty
willingly at this point.
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
More information about the Mercurial-devel