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

[Theodore Tso]

On Fri, Jan 09, 2009 at 03:18:53AM -0600, Matt Mackall wrote:
> Maybe. There are a number of places where schemas are different enough
> to make hash-preserving round-tripping between git and Mercurial
> difficult:
> 
> - mercurial tags vs git tags
> - mercurial branches (no direct git analog)
> - git branches vs mercurial bookmarks
> - mercurial signatures vs git signatures
> - git committed-by
> - mercurial copy/rename data
> - mercurial manifests vs git trees
> - git octopus merges (no mercurial analog)
> - mercurial file indexes and linkrevs

What I was thinking would require accomodations for developers on both
sides to make things work.  Specifically, on the Hg front, developers
would have to use mercurial bookmarks instead of mercurial branches
and tags.  On the git side, uses of git octopus merges would not be
allowed.

There would definitely need to be some state that would have to be
stashed at the end of the commit log.  This would include the foreign
commit ID's (i.e., the hg commit ID if the commit originally
originated from hg, the git ID if the commit originally originated
from the git universe, etc.), and other information that's not tracked
by the other system.  (i.e., the git commiter ID, and mercurial
copy/rename information).

If there is only one hg<->git gateway, life is much easier, since we
don't have to make sure that the two gateways, if they both see a new
commit on one side of the gateway (for example, a new git commit), we
don't have to results in an identical commit with same hash ID on the
other side.  If we do that, then a new commit on the git side can
simply use git's copy/move detection algorithms, and if it doesn't
quite get it right, it will be unfortunate, but it's not the end of
the world.  Something similar can be done for the linkrev information;
it can be generated hueristically by the hg<->git gateway.

It's not perfect, but the fact that the use of Mercurial bookmarks
means that the two DAG's seen by git and mercurial will at least have
exactly the same shape, which was one of the hardest parts of the
problem.

In fact, if we use the simplifying assumption that there's only one
gateway, the only information we _have_ to store in the commit log is
the foreign commit ID.  Other things such as the git committer ID are
useful in case the hg user wants to see information collected by the
remote system, but it's not strictly necessary; as long as the gateway
can recognize that this commit originally came from the remote DSCM,
and can match it up with the ID on the other side, that's all it
really needs.  

There are more complicated ways we could do things; for example, the
information from the foreign system could be stashed in a hg-specific
or git-specific location.  For example, hg could grow the ability to
optionally store the committer ID, or maybe the git developers could
add new (optional) fields to git's commit object.  This would only be
useful mainly has an aesthetic issue, to clean up the inband-storage
of the information in the commit comments.  (Of course, we could also
add changes to "git log" or "hg log" to suppress such information,
too.)   But whether any of this gets done is really niceties.   

IMHO, the bookmarks functionality is the biggest issue.

> It'd probably be easier to simply make a git format back-end for
> Mercurial. This is probably less work than making a Mercurial back-end
> for git as Mercurial's repository operations are already moderately well
> isolated by its repository and context objects. But I certainly don't
> have the patience for it.

Perhaps, but that doesn't allow git users to operate on hg
repositories natively using git.  And it's likely that a much smaller
percentage of hg extensions would actually work given such a scenario.

Forthermore, you'd have to either (a) replicate all of git's copy/move
detection hueristics, and deal with the fact that git doesn't record
the linkrev information, or (b) require that git be installed and
simply use the hg comand/options parser be a front-end to git.  But in
the case of (b), why not just create a shell script that maps hg
commands to git commands, and maybe lightly frobnicate's git's output
so it looks a lot more like hg?   It might be a lot easier....

      	      	       	    	     	   - Ted