Promoting the use of Mercurial; was: Re: gnome dvcs survey results

[Theodore Tso]

On Sat, Jan 10, 2009 at 09:11:22AM +0100, Arne Babenhauserheide wrote:
> 
> Maybe this could be solved by hiding merge commits which are part of an 
> octopus merge in the log and showing only one merge instead. 
> 
> I did something similar with the group extension: 
> - http://www.selenic.com/mercurial/wiki/index.cgi/GroupExtension

That's a good idea; I hadn't Relized that extensions posessed the
ability to make that sort of changes to core Hg functionality.

> > Well, you have to be able to go both ways, with the initial gateway,
> > or it's not useful.  You have to be able to populate the bridge repo
> > somehow, and once you have that, and the ability to push new hg
> > changes to the git repo, you've got your bidrectional gateway.....
> 
> As long as git doesn't offer a similar gateway that will force git
> developers to use a hg repo as intermediate and push from that to
> their own git repos, so I think that it will give some pressure for
> git people to create a Mercurial bridge as well.

Well, we already have one-way bridges that will do incremental
conversions from hg->git and from git->hg.  Those exist already; Matt
put one together long ago which does incremental conversions of the
Linux git repo to Hg, and there are similar utilities that can convert
hg repo's to git repo's.  However, a bi-directional bridge requires
that the conversion utilities in each direction be carefully crafted
to work with each other --- and once you build such a thing, by
definition it works in the opposite direction.

Consider, suppose you have a bridge that can take a fully populated
git repository (say, the Ruby on Rails repo), and convert it into an
Hg bridge repository.  Now developers who would like to us Hg can
clone from the bridge repository, and work on that.  So far, they can
do this already using one of a number of one-way git->hg conversion
utility that exist already.  Now they push a series of commits, and
they would like to submit it for inclusion in mainline, so that their
work is not in vain.  Today, they can use the patchbomb extension to
submit the patch series via e-mail, but then they are participating as
2nd class citizens, and other Ruby on Rails developers can't easily
pull their changes for testing in integration trees before they are
submitted into the mainline.  Thus enters the bridge that works in
both direction, which converts their hg commits into a series of git
commits in a "git bridge repository", and now the developers who would
like to use Hg as their DSCM can send an e-mail request asking people
who would like to test their work can pull from a particular branch in
the git bridge repo, and eventually their patches can get pulled into
the master git repository for Ruby on Rails.  Problem solved.

But note that once you have this two-way bridge, it can be used to go
in the opposite direction.  Except now you start with an empty git
repository, and a fully populated Hg repository, and the same tool
which took the newly created development commits from the developers
using Hg and converted them to git commits, is now going to convert
the entire Hg repository into git commits, since from the perspective
of the gateway, all of the existing Hg commits are "new commits" that
need to be converted to git commits. 

You see?  So it's not the case of "the mercurial community creates a
bridge utility, this will create pressure for the git community to
create their own bridge utility for use in the opposite direction".
No, there needs to be a *single*, well constructed bi-directional
gateway, that can convert "foreign" commits to "local" commits in such
a way that regardless of whether Hg or git is considered "foreign" or
"local", the resulting commits look good and can be treated as
first-class commits in both systems.  

If moving forward, we have to tell both git and hg users, look you
both have to make some sacrifices; in order for this to work Hg users
have to use Bookmarks for tags and branches, and git users have to
give up on octopus merges, that may be important from a
social/political point of view.  And from the point of view of the OSS
project, hopefully they would be willing to enforce this for all
future development because that way they can draw from a much larger
developer pool.  It would no longer be the case that an Hg user might
be discouraged from contributing to Ruby on Rails because s/he isn't
comfortable with git, or that a git user might be discouraged from
contributing to Mozilla because s/he isn't comfortable with Hg.


This also implies that if this is going to get done as a GSOC project,
ideally there would be participants from **both** communities
supervising and critiquing the design.  In order for this bridge to be
successful, and not yet-another-git-to-hg-or-hg-to-git converter, it
has to be bidiretional, and its output needs to be something that
looks good and as close as "native" as possible for both the Hg and
Git communities.

						- Ted