Mercurial vs Git

[Felipe Contreras]

Hi,

So you are thinking on switching away from monotone, that's great.

As you might know, I am extremely familiar with Git, as I'm a contributor, and
I've analyzed Mercurial for the sake of comparison[2]. Mercurial doesn't have
most of the disadvantages I listed on the "Monotone analysis", in
fact, to me it's
very similar to git. However, there's a big difference: branches.

== branches ==

In git, branches are distributed, which means that if you have 2 developers
with 2 branches each, that doesn't mean that by sharing their repos, they would
have 4 branches.

'git branch -a' would show:
 origin/master
 darkrain/master
 darkrain/buddy-add
 darkrain/docs
 khc/master
 khc/msnp14
 khc/msnp14.ticket393

(This is similar to what mercurial bookmarks extension would show, except that
the 'khc/' prefix would not be there.)

IOW; not everyone has to see the branches of everyone, you manually add which
repositories you want to follow, and when you do 'git fetch', you would see the
branches in that particular repository updated.

And of course, branches are disposable (supposing I'm 'darkrain'):

 git checkout master
 git merge docs # the commit would say 'Merge branch 'docs' into master
 git push origin master # push the 'master' branch to the 'origin' repo
 git branch -d docs # delete this branch which won't be used any more

If for some reason you want everyone to see your branch:

 git push origin docs:darkrain.docs # pushes the local docs branch as
 	'darkrain.docs' to 'origin'

This is why it's possible in the linux kernel to have hundreds of maintainer
repositories, each one with dozens of branches and patches coming from the
branches of even more developers. Branches are merely a utility to identify
commits.

I haven't seen anyone discuss this fact, except John Bailey who called the git
implementation 'braindead' without going into any details.

== graft points ==

I saw a proposal from John Bailey to have a structure like:

libgnt
libpurple
finch
 |-- libgnt
 |-- libpurple
 `-- po
pidgin
 |-- libpurple
 `-- po
po

The disadvantage, he claimed, is that the history would have to start from zero
since otherwise each one of these repos would have to be 215 MB.

Not with git.

My proposal would be the following. Convert the whole history to git, then,
make a new release, say 2.8 where the directories are split (libpurple, pidgin,
etc.). That repository would be the legacy one, then, start new separate
repositories that start from scratch.

Then, for the people that want to have the full history, they can setup a
graft-point[3] and voilá; the full history would be available on each one of the
repos.

== Mercurial side projects ==

No biggie, it's easy to convert form hg to git, so the hg version can be
offered as well.


In conclusion, everything that can be done with Mercurial can be done with
Git, but not the other way around (at least I'm pretty sure about the
branches). Therefore, the sensible choice IMO is Git.

I'm not subscribed to the list, so please 'reply-to-all'.

Cheers.

 [1] http://pidgin.im/pipermail/devel/2008-July/006308.html
 [2] http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches/
 [3] https://git.wiki.kernel.org/index.php/GraftPoint

-- 
Felipe Contreras