Subject: Re: Mercurial vs Updated git HOWTO for kernel hackers

From: "Sean" <[email-masked]>
Date: Tue, 28 Jun 2005 20:25:02 -0400 (EDT)

On Tue, June 28, 2005 8:08 pm, Kyle Moffett said:

> Firstly, no need to shout, we can all hear you :-D.

ok

>
> Git and Mercurial have all of the same core functionality.  The only
> significant remaining difference is that Mercurial uses 1/20th the
> network bandwidth and disk space.  If you happen to be interested in
> that advantage (as I am, due to my aging equipment and poor internet
> connection), then there are two options: (1) fix git, or (2) just use
> Mercurial.  From my point of view, option 2 is much more productive.
> You may (and probably do) have different priorities and requirements
> than I do, but in my view, Mercurial is an excellent tool.

well the feature set for both are changing rapidly.  i like the emphasis
placed on functionality over performance shown by the git developers (not
that git is slow, it's _way_ faster than bk ever was).  also the web
interface that i looked at for mecurial (admittedly four or fivve weeks
back) didn't come close to gitweb.   and the work done by jon seymour and
others on the history lineralization is just great.   it's something bk
lacked and was always a thorn in my side.

> Actually, Mercurial solved some of the problems first, before git did;
> distributed merge is one example that comes to mind.  In any case, I'm
> not trying to tell you what to use, I'm just pointing out alternatives
> that are available and explaining why I like them, in case you haven't
> seen them or tried them before.

there will be a price to pay if the linux community fragments over choice
of scm.  the good news is that we're no longer locked into the whims of
some proprietary system.  so it should be straight forward for those who
choose any tool to work with those who've chosen another.  this is already
evidenced by the fact that the git repository is pulled and re-exeported
with mecurial.

anyway, all the best, just wish you guys would spend less time trying to
convert git users and more time advancing your own tool.

sean