Mercurial vs Git
felipe.contreras at gmail.com
Wed Jan 19 18:17:12 EST 2011
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. 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:
(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
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:
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 and voilá; the full history would be available on each one of the
== 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'.
More information about the Devel