From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Cc: mercurial@selenic.com
Subject: Re: [VOTE] git versus mercurial (for DragonflyBSD)
Date: 26 Oct 2008 15:15:57 +0100 [thread overview]
Message-ID: <m3r663h276.fsf@localhost.localdomain> (raw)
In-Reply-To: ge0rla$mce$1@ger.gmane.org
[Cc: gmane.comp.version-control.git,
gmane.comp.version-control.mercurial.general]
walt <w41ter@gmail.com> writes:
> No, no, I'm not the one calling for a vote. You old-timers here
> will know the name Matt Dillon, who is leading the dragonflybsd
> project (www.dragonflybsd.org).
>
> Matt is the one who is calling for the vote in his thread "Vote
> for your source control system" in the dragonfly.kernel group,
> accessible via nntp://nntp.dragonflybsd.org.
>
> I've already cast my vote for git, which I confess is not very
> honest because I've never even tried mercurial. I would truly
> be grateful to anyone here who knows both git and mercurial who
> could contribute verifiable facts to that debate.
I also used only Git, but I have read a bit about Mercurial; however
the information I have on Mercurial might be out of date.
Below I have tried to compare Git with Mercurial, pointing the most
important (to me) facts:
1. Documentation and ease of use.
Mercurial is supposedly better documented and easier to use; I
think this descends from the early days of Git, where it was not
very user friendly. IMHO Git has much improved since. Mercurial
had 'hgbook' from the beginning; Git User's Manual is more recent.
I also think that ease of use is just different learning curve.
I am also biased and I think that Mercurial starts easy, but it has
more difficult things (like e.g. merging, multiple branches in
single repository etc.) harder than it Git.
I'll admit that Mercurial UI is better designed; Git UI was not as
much designed as it evolved from 'stupid content tracker' to
full-featured SCM, therefore there are a few oddities (for example
git-revert might do not what you expect, if you are accustomed to
Subversion UI).
2. Implementation, portability, bindings and extending
Mercurial is implemented in Python, with core written in C for
better performance. It has a plugin system, and additional extra
features implemented through extensions. I don't know what is the
status of bindings (or implementations) in other programming
languages; but it has some API for use in extensions at least.
Git is implemented as mixture of C, shell scripts, Perl and Tcl/Tk
(for GUI). The main way of extending it is by scripting around
powerfull set of low level tools, called 'plumbing', meant to be
used in scripts. JGit is for example _reimplementation_ of Git in
Java.
3. Repository design and performance.
Git is designed around idea of content adressed object database;
objects are adressed by their content (by SHA-1 of their type and
content). Commits for example have information about author and
comitter, pointer to zero or more parent commits, and pointer to
tree object (representing top directory in project). Branches
and tags are just pointers to DAG (Direct Acyclic Graph) of
commits; current branch is denoted by HEAD pointer to branch.
There is explicit staging area called 'index', used for conflict
resolution dureing merges, and which can be used to make commit in
stages, allow uncomitted changes in tree (in working directory).
Git design supports very well multiple branches in single
repository, and tracking changes in multiple remote repositories
each with multiple branches.
Mercurial, from what I have read of its documentation, and from the
few discussion on #revctrl IRC channel, and from what I understand
is based on changes stored per file, with information about files
and their versions stored in manifest (flat) file, and with changes
described in changelog-like file (changerev). One of limitations
of "record" database (as opposed to Git's object database) is that
commits can have zero (root commit), one or two (merge commits)
parents only. There is apparent in design that Mercurial was
developed with single branch per repository paradigm in mind.
Local branches from what I understand are marked in CVS-like
fashion using tags. Tags are implemented as either local to
repository and untransferable, or as .hgtags versioned file with
special case treatment. (But I'm obviously biased here).
Git and Mercurial have similar performance, although it is thought
that due to design Mercurla has faster patch applying and is
optimized for cold cache case, while Git has faster merging and is
optimized for warm cache case.
Mercurial may have (or had) problems with larger binary files, from
what I have heard.
3. Advanced features, interfaces and tools
I don't know much about Mercurial beside basic usage, what I
remember from 'hgbook', but I think that most if not all advanced
Git features are available either in Mercurial core, or as
Mercurial extensions (plugins).
For example both Git and Mercurial have bisect command for finding
bug by searching (possibly nonlinear) history for commit which
introduced bug, ForestExtension is rough equivalent of git
submodules (or third party git-externals), there is Transplain
extension for git-rebase, etc.
Mercurial has hgserve which can function as both web repository
browser and as anonymous server; in Git they are split between
git-daemon for anonymous repository access, and gitweb (or other
web interfaces: cgit, git-php, ViewGit, Gitorious,..) for web
interface.
NOTE: In Git repacking and garbage collecting is explicit
(although can be automated with "git gc --auto", and some of it
happens automatically); Git use _rename detection_ rather than
_rename tracking_, which has its advantages and disadvantages.
They are many articles comparing Mercurial and Git; if they are blog
posts please read the comments too. Among them are:
* "Git vs. Mercurial: Please Relax" (Git is MacGyver, Mercurial
is James Bond)
http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/
* "The Differences Between Mercurial and Git"
http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/
* "Git vs. Mercurial"
http://blog.experimentalworks.net/archives/38-Git-vs.-Mercurial.html
* "Git versus Mercurial..."
http://codeheadsystems.wordpress.com/2008/05/10/git-versus-mercurial/
* "Git vs Mercurial"
http://www.simplicidade.org/notes/archives/2007/12/git_vs_mercuria_1.html
Note however that the comparison at "Better SCM Initiative" has some
wrong information about Git: see
* "Git at Better SCM Initiative comparison of VCS (long)"
http://thread.gmane.org/gmane.comp.version-control.git/95809/focus=97253
--
Jakub Narebski
Poland
ShadeHawk on #git
next prev parent reply other threads:[~2008-10-26 14:17 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 ` Jakub Narebski [this message]
2008-10-26 14:30 ` [VOTE] git versus mercurial (for DragonflyBSD) 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
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=m3r663h276.fsf@localhost.localdomain \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=mercurial@selenic.com \
/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).