I have a small project with the potential to grow. We are a disparate team in different time-zones and with different outside commitments, and we're trying to pick a distributed source-code versioning system to use. To some extent we don't much care, but it would be nice to see an even-handed comparison between our two main contenders - Mercurial and git.
Both of these are good tools --- you won't go too far wrong no matter which one you choose.
In brief:
The strength of Mercurial is that it has a fairly simple set of basic commands. These commands are easy to use and the documentation for these commands is way less daunting than those for git commands. Using Mercurial out of the box, without enabling extensions, it is harder to screw things up in a way that destroys history. At the same time, it may be harder to manipulate the contents of a Mercurial repository in ways you want. However, there are extensions for Mercurial, some third-party, some that come with the system, that let you do many of the manipulations that git provides.
Git's command set and UI are more complicated than Mercurial's. But, you don't have to learn them all at once, so just getting to a point where you can get basic stuff done isn't difficult. The strength of git is that it has fairly straightforward conceptual underpinnings, and once you start thinking of commands in terms of how they manipulate the underlying structure of your repository (see, for example, http://www.slideshare.net/chacon/getting-git for details), it's a very empowering system (or, if you're a pessimist, you've been given enough rope).
A not uncommon pattern is for people to start out with Mercurial, perhaps because the learning curve isn't as steep or because it had clearly better Windows support at one time, and then switch to git as their usage pattern requires more complicated functionality than Mercurial easily provides. An example of this is: http://lucumr.pocoo.org/2010/8/17/git-and-mercurial-branchin...
I have experience with both, but don't have a clear preference...
Hg, overall, seems a bit more user friendly for doing the run-of-the-mill things such as branching, merging, fetching code, delivering patches, etc. I find it more pleasant to use without knowing much about the internals. This makes it also easier to explain to people that used SVN etc.
Git has a lot of 'magical command line switches', and (at least used to be) documented qutie sparsely. So you'll probably query google on how to get out of seemingly simple situations. On the other hand, Git allows a guru to do a lot of stuff such as re-ordering history to make nicer patches. Once you master how things work, these can be very useful.
IMO, it doesn't really matter that much, you'll get used to both, and Hg and GIT are more or less equivalent feature-wise.
With the addition of the git-flow plugin, git has taken over for my personal projects. The branching model works for me and the plugin makes using that branching model extremely easy.
Before git, I never understood version control. svn seemed way too mysterious, and I was supposed to use commands without understanding what's going on, and it just never settled with me.
With git, the system is so simple to understand, and so finally it makes sense. The commands are rather clean and friendly. I don't have anything to complain about.
With hg, it's almost back to svn. I didn't really know how things worked; I never wrapped my head around it, so I never used it.
I only have experience with git, so I can't compare the two directly. That said, there are a few pseudo-features I love which aren't part of git itself:
1. GitHub (bitbucket doesn't seem comparable)
2. Aptana's built-in support for git
Is there even a decent Windows shell extension for git yet? When using Windows and teams not already familiar with git, Mercurial + TortoiseHG was an easy choice.
Msysgit is what I use and I really enjoy it. Git also has a Visual studio plugin now you can use if you prefer GUI to CLI.
I don't know enough about mercurial to offer a good opinion, does it offer something equivalent to hooks in git for setting up custom behavior?
I don't know if it's decent, I'm a Linux user but there's TortoiseGit:
http://code.google.com/p/tortoisegit/
Current version is 1.6.3.0, so looks like it's considered stable enough to be beyond the 0.x-stage... ;)
[+] [-] Ratufa|15 years ago|reply
In brief:
The strength of Mercurial is that it has a fairly simple set of basic commands. These commands are easy to use and the documentation for these commands is way less daunting than those for git commands. Using Mercurial out of the box, without enabling extensions, it is harder to screw things up in a way that destroys history. At the same time, it may be harder to manipulate the contents of a Mercurial repository in ways you want. However, there are extensions for Mercurial, some third-party, some that come with the system, that let you do many of the manipulations that git provides.
Git's command set and UI are more complicated than Mercurial's. But, you don't have to learn them all at once, so just getting to a point where you can get basic stuff done isn't difficult. The strength of git is that it has fairly straightforward conceptual underpinnings, and once you start thinking of commands in terms of how they manipulate the underlying structure of your repository (see, for example, http://www.slideshare.net/chacon/getting-git for details), it's a very empowering system (or, if you're a pessimist, you've been given enough rope).
A not uncommon pattern is for people to start out with Mercurial, perhaps because the learning curve isn't as steep or because it had clearly better Windows support at one time, and then switch to git as their usage pattern requires more complicated functionality than Mercurial easily provides. An example of this is: http://lucumr.pocoo.org/2010/8/17/git-and-mercurial-branchin...
[+] [-] wladimir|15 years ago|reply
Hg, overall, seems a bit more user friendly for doing the run-of-the-mill things such as branching, merging, fetching code, delivering patches, etc. I find it more pleasant to use without knowing much about the internals. This makes it also easier to explain to people that used SVN etc.
Git has a lot of 'magical command line switches', and (at least used to be) documented qutie sparsely. So you'll probably query google on how to get out of seemingly simple situations. On the other hand, Git allows a guru to do a lot of stuff such as re-ordering history to make nicer patches. Once you master how things work, these can be very useful.
IMO, it doesn't really matter that much, you'll get used to both, and Hg and GIT are more or less equivalent feature-wise.
[+] [-] jere_jones|15 years ago|reply
Link to explanation of branching model: http://nvie.com/posts/a-successful-git-branching-model/
Link to git-flow plugin: https://github.com/nvie/gitflow
Link to video intro for git-flow: http://vimeo.com/16018419
[+] [-] nyellin|15 years ago|reply
[+] [-] hasenj|15 years ago|reply
With git, the system is so simple to understand, and so finally it makes sense. The commands are rather clean and friendly. I don't have anything to complain about.
With hg, it's almost back to svn. I didn't really know how things worked; I never wrapped my head around it, so I never used it.
[+] [-] nyellin|15 years ago|reply
[+] [-] markstahler|15 years ago|reply
[+] [-] Jacquass12321|15 years ago|reply
[+] [-] JustAGeek|15 years ago|reply
[+] [-] yuvadam|15 years ago|reply