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

[Theodore Tso]

On Thu, Jan 08, 2009 at 01:23:06PM -0600, Matt Mackall wrote:
> 
> This argument always puzzles me. You can certainly write an 'extension'
> as a shell script today in Mercurial, you'll just have to name it hg-foo
> rather than 'hg foo'. And, just like git, it'll have to go through other
> built-in commands to do its job. Nor will it have any help with argument
> parsing, online help, etc. Extending our extension support so that we
> can make arbitrary commands work as 'hg foo' is something nobody but you
> has ever even hinted at.

I won't say it's an argument, but rather an observation.  And the
obeservation is that there is a much greater level of access to the
low-level internals of git via git's internal "plumbing" layer than
there is available in Mercurial.  The conflation of commands that give
access to git's internal state ("plumbing") versus those commands
intended for end user use ("porcelain") is the basis of complaints
that git is hard to understand.  So that's a problem which has been
addressed in git 1.6.x series, which has made a sharp delineation
between the two.  This has certainly helped to address complaints that
users of git need to learn "hundreds of commands" (which was never
true, but hiding the more esoteric commands has definitely helped from
an approachability and easy-of-learning point of view).

However, the key is that git *has* a plumbing layer, whereas hg does
not.  Its lack certainly makes hg simpler, but it means that there
exists a certain class of extensions which *must* be implemented in
Python, or at least partially in Python, since there isn't access to
such low-level interfaces for non-Python programs.  (And the low-level
python interface aren't terribly well documented either, compared to
the git plumbing man pages.)

> This of course begs the question: why does git still suck? If they have
> six times the people power, you'd think that over the last 3 years they
> would have pulled so far ahead in quality that hg and bzr wouldn't even
> be on people's radars. But git's kluge-ness is deeply embedded in its
> DNA and evolving away from that is apparently going to take geological
> time. 

Well, two years ago, git and hg were roughly tied, at least in terms
of the number of projects who use it, and from my perception of what
DSCM various OSS developers might choose to use.  The Gnome DCVS
survey came as a shock to me (and apparently others) since it has
shown that in terms of mindshare, git has made some fairly impressive
strides, at least in one particular community.

The fact that there has been quite this much change is quite
surprising, given that once developers get used to a tool, they
generally quite slow to adopting others.  On top of that, once a
project adopts a SCM, that tends to strongly bias developers towards
using that SCM if they want to interact efficiently with that project.
If you don't believe me, consider how many developers are still using
svn or even CVS, despite the availability for far superior SCM tools.
So the fact that apparently git has managed to pull ahead as much as
it has is saying something.

As far as "why git does still suck", there's a loaded question if I
ever saw one.  :-) Each person has their own reasons for believing why
say, vi sucks and emacs is the best editor that ever sliced bread, or
vice versa.  <grin>  I've deliberately tried to stay away from
discussions about attributes that DSCM <foo> might posses that DSCM
<bar> does not, and whether or not those differences should matter --- 
which is generally how those debates generally tend to devolve, 
usually shedding far more heat than light.

My personal hope is that it does become possible to build a
bidirectional gateway between a project's hg repository and git
repository, such that each user can choose whichever tool they are
most comfortable with to do their development.  The situation we have
right now would be equivalent to if, in order to be a first-class
developer in project X, you needed to use emacs as your text editor,
but in project Y, in order to participate fully and deeply, you need
to use vi as your text editor.  If that were true, we'd all agree that
it would be a pretty horrific state of affairs, right?  Yet that's
what we have today with DSCM's.

I'm hopeful that if the Bookmarks extension gets a bit more fully
developed, a full two-way, bidirectional repository conversion tool
capable of doing incremental conversions (and so could be used as a
gateway) would be quite feasible.  Incompatibility between hg's and
git's notions of how tags and branches work is one of the biggest
stumbling blocks; but bookmarks might prove to be a way of working
around that particular problem.

						- Ted