Julian Gonggrijp <j.gonggrijp@gmail.com> writes: Hi, This discussion was mentioned on the Mercurial mailinglist. I'm a Mercurial developer, but let me start by saying that you will be very happy with both tools. DVCS is a great step up from SVN and people rarely look back.
FWIW, I am the last person who will oppose such a change. But currently, noone presented a fair reasoning in favor for git,
Well, allow me to present some fair reasoning to you.
With regard to git versus svn: I think enough fair reasons have been given why git (or a DVCS in general) is better than svn. I'm not going to repeat those arguments here.
With regard to git versus mercurial: given that it's probably a good idea to switch to a DVCS, git and mercurial seem to be the primary candidates. I think everyone in this thread should be more willing to admit that they're close competitors. In many ways they're about equally "good", and when they aren't the differences are quite moot:
- mercurial has native support for Windows, but git is also fairly well supported on Windows and seems to be rapidly improving;
Yes, both tools work on Windows.
- git allows you to edit history while mercurial doesn't, but which you like better is a matter of preference;
This statement is *false*. I'm not sure where you've read it? Both tools let you modify the history and with the same consequences. Editing history really means creating a new history and throwing away the old history and they both support this. There is a non-technical difference, though: Mercurial has a *bias* towards immutable history in its command set. Technically it can throw away your history just like Git can throw it away.
- git seems to be more "powerful" and less susceptible to errors, while mercurial is said to have better documentation -- while this doesn't make either objectively better than the other in the first place, they're also both catching up on their weaker side;
I fully believe that Git and Mercurial is equally powerful. Their internal concepts are very, very similar. You can map between the tools in a nearly loss-less way (see the hg-git extension). To me, arguing that Git is more powerful since it exposes more commands by default ('git rebase -i' is the typical example) is like arguing that Perl is more powerful than Python since Perl has a built-in regex operator -- we all know that both languages are Turing complete.
- they are built with very different architectures (many executables written in C versus a monolithic program in Python), but in the end both work well enough and both seem extensible enough for most purposes.
Both are great tools and both will work well for a big and complex project like Boost. Mercurial has some new features which isn't found in other systems: - Revision sets: a query language that lets you select commits. An example from [1] is hg log -r "1.3::1.5 and keyword(bug) and file('hgext/*')" This syntax can be used with all commands that take a -r flag. - File sets: similar to revsets, but for selecting files. An example from [2] would be hg revert "set:copied() and binary() and size('>1M')" I think formulating the equivalent query with find(1) would be hard. - Heavy-weight branches: Mercurial has named branches which are built into the changesets. This lets you track exactly where a branch started and where it ended. These branches are very *different* from branches in Git: they are permanent and global. In this way, named branches are much more similar to branches in CVS and SVN. The closest equivalent of Git's branch model is called bookmarks in Mercurial. See the glossary[3]. [1]: http://www.selenic.com/mercurial/hg.1.html#revset [2]: http://www.selenic.com/mercurial/hg.1.html#fileset [3]: http://www.selenic.com/mercurial/hg.1.html#glossary -- Martin Geisler Professional Mercurial support by aragost Trifork http://www.aragost.com/mercurial/