git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Miklos Vajna <vmiklos@frugalware.org>
Cc: Pieter de Bie <pdebie@ai.rug.nl>,
	Peter Krefting <peter@softwolves.pp.se>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)
Date: Tue, 28 Oct 2008 17:31:44 -0400	[thread overview]
Message-ID: <20081028213144.GC10862@mit.edu> (raw)
In-Reply-To: <20081028191234.GS24201@genesis.frugalware.org>

On Tue, Oct 28, 2008 at 08:12:34PM +0100, Miklos Vajna wrote:
> On Tue, Oct 28, 2008 at 04:33:54PM +0100, Pieter de Bie <pdebie@ai.rug.nl> wrote:
> > fast-import yet. If I understand dscho correctly, that exists now, so it 
> > should be easy enough to integrate that as well.
> 
> That's new to me. Theodore Ts'o once mentioned on this list that there
> is a "hg fast-export" but actually he just referred to "there is a
> git2hg conversion tool in hg's contrib dir" and it has nothing with
> fast-import.

The code I was referring to was called hg-fast-export, which is part
of the "fast export" tools that front-end into git fast-import.  The
git repository can be found here:

	http://repo.or.cz/w/fast-export.git
	git://repo.or.cz/fast-export.git

I ended up using a very customized version of that script to convert
the hg e2fsprogs repository to git.

In the past I've looked at the possibility of creating a
bi-directional, incremental gateway between hg and git repositories.
The main thing which makes this difficult is that hg stores tags
in-band inside the change-controlled .hgtags file.  This means that if
you cut a release, tag it, and then create a commit to further modify
the repository, the new commit is descended from the tag commit,
whereas in git, the tag is a "bookmark" --- perhaps signed via GPG,
but not part of the revision history.

I think the git method is much more sane, but what it means is that
topologically, the commit tree for git and hg can never be identical.
It also means that if you add a tag to a git tree after making several
commits on that branch, how you reflect that in the hg repository is
highly problematic.  Do you rewrite the branch?  Do you add the tag
later on, disturbing the parent-child relationship of later commits?
How do you keep track of when a tag hg repository topology if you are
trying to maintain a bidirectional mapping between commits?

It's not impossible, but it makes it much more difficult, since in the
hg world, tag commits can be inserted between arbitrary commits.  This
also means that if you want to create a bidrectional gateway between
hg and git, it has to be a single gateway so it can keep track of this
state information.  If you try to have multiple gateways they would
need to synchronize on when a tag entered the hg universe, and with
what commit ID (and what timestamp).

						- Ted

  parent reply	other threads:[~2008-10-28 21:33 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-26  4:28 [VOTE] git versus mercurial walt
2008-10-26 14:15 ` [VOTE] git versus mercurial (for DragonflyBSD) Jakub Narebski
2008-10-26 14:30   ` Maxim Vuets
2008-10-26 15:05     ` Leo Razoumov
2008-10-26 18:55       ` Jakub Narebski
2008-10-27  0:20         ` Arne Babenhauserheide
2008-10-27  4:15           ` Leo Razoumov
2008-10-27  7:16             ` Arne Babenhauserheide
2008-10-27  7:16             ` dhruva
2008-10-27  0:47         ` Arne Babenhauserheide
2008-10-27  1:52           ` Jakub Narebski
2008-10-27  7:50             ` Arne Babenhauserheide
2008-10-27  9:41               ` Jakub Narebski
2008-10-27 10:12                 ` Leslie P. Polzer
2008-10-27 10:14                 ` Arne Babenhauserheide
2008-10-27 12:48                   ` Jakub Narebski
     [not found]                     ` <200810271512.26352.arne_bab@web.de>
2008-10-27 18:01                       ` Jakub Narebski
2008-10-27 20:48                         ` Arne Babenhauserheide
2008-10-27 21:07                           ` Miklos Vajna
2008-10-27 21:30                             ` Arne Babenhauserheide
2008-10-28  0:13                               ` Miklos Vajna
2008-10-28 17:48                               ` Andreas Ericsson
2008-10-28 19:11                                 ` Arne Babenhauserheide
2008-10-28 19:38                                   ` SZEDER Gábor
2008-11-06 16:25                                     ` Marcin Kasperski
2008-11-06 17:41                                       ` Isaac Jurado
2008-10-28 19:16                                 ` Randal L. Schwartz
2008-10-27 23:25                           ` Jakub Narebski
2008-10-27  9:29             ` Benoit Boissinot
2008-10-27 10:57               ` Jakub Narebski
2008-10-27 14:29                 ` 0000 vk
2008-10-27 14:57                   ` Jakub Narebski
     [not found]             ` <1225100597.31813.11.camel@abelardo.lan>
2008-10-27 11:42               ` David Soria Parra
2008-10-27 20:07             ` Brandon Casey
2008-10-27 20:37               ` Jakub Narebski
2008-10-28  1:28                 ` Nicolas Pitre
2008-10-26 15:57   ` Felipe Contreras
2008-10-26 19:07     ` Jakub Narebski
2008-10-26 19:54       ` Felipe Contreras
2008-10-28 12:31 ` [VOTE] git versus mercurial walt
2008-10-28 14:28   ` Johannes Schindelin
2008-10-28 14:41     ` Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial) Peter Krefting
2008-10-28 14:59       ` Johannes Schindelin
2008-10-28 15:02         ` Git/Mercurial interoperability (and what about bzr?) Matthieu Moy
2008-10-28 15:03       ` Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial) Nicolas Pitre
2008-10-28 15:33       ` Pieter de Bie
2008-10-28 19:12         ` Miklos Vajna
2008-10-28 21:10           ` Miklos Vajna
2008-10-28 21:31           ` Theodore Tso [this message]
2008-10-28 23:28             ` Miklos Vajna
2008-11-01  8:06             ` Git/Mercurial interoperability (and what about bzr?) Florian Weimer
2008-11-01 10:03               ` Santi Béjar
2008-11-01 10:33               ` Jakub Narebski
2008-11-01 10:44                 ` Florian Weimer
2008-11-01 11:10                   ` Florian Weimer
2008-11-01 12:26                   ` Jakub Narebski
2008-11-01 13:39                   ` Theodore Tso
2008-11-01 17:51                     ` Linus Torvalds
2008-11-02  1:13                       ` Theodore Tso
2008-11-01 10:16         ` Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial) Peter Krefting
2008-10-29 19:11     ` [VOTE] git versus mercurial Shawn O. Pearce
2008-10-29 19:36       ` Boyd Lynn Gerber
2008-10-29 19:48         ` Johannes Schindelin
2008-10-29 19:51           ` Boyd Lynn Gerber
2008-10-29  8:15   ` Miles Bader

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081028213144.GC10862@mit.edu \
    --to=tytso@mit.edu \
    --cc=git@vger.kernel.org \
    --cc=pdebie@ai.rug.nl \
    --cc=peter@softwolves.pp.se \
    --cc=vmiklos@frugalware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).