Git vs Mercurial: Google Code Analysis(code.google.com)
code.google.com
Git vs Mercurial: Google Code Analysis
http://code.google.com/p/support/wiki/DVCSAnalysis
28 comments
You should keep in mind that this evaluation was done more than a year ago.
That makes more sense on some of the stuff, but the auto gc and non-fast-forward server options are both older than that. If it was done that long ago, I can't find any mention of it in the paper, and people will use this, being from an authority like Google to enforce wrongful beliefs about the systems. If the document is that old, it should have been prefaced with that information - it looks to have been posted no more than a day ago.
The fact that Git can actually lose history is one bad mark against it. The fact that the option to prevent this has the totally bizarre name of "denyNonFastforwards" is another.
First of all, you can lose local history in Hg too, by running 'hg rollback' and I _believe_ you can also do it with the 'rebase' extension (which was implemented because developers find that functionality in Git so useful). However, these are the exact same ways you can rewrite history in Git.
Second, the 'receive' setting is not for normal users - it is not run client side. It is an option for the people running the Git server and is not normally needed. If you trust your fellow developers enough not to commit something idiotic, then you can trust them to manage the head references properly. However, if your company has some super paranoid and poorly considered policy, then it is an option.
We do not enforce this at GitHub and not only has it never been a problem, but it has helped us help people solve issues that they do have - accidentally committing files you really don't want in there, or code with a license you actually cannot use or something. With Git it's relatively easy to fix the repository and force push the update and let your collaborators know this needs to be done. With Mercurial... I honestly don't know how you can deal with that.
Furthermore, it doesn't actually lose the changes, it just removes the pointer to them, you can push the old pointer back very easily. So, if you think this is an entirely 'bad thing', then I feel you misunderstand what it really means.
Second, the 'receive' setting is not for normal users - it is not run client side. It is an option for the people running the Git server and is not normally needed. If you trust your fellow developers enough not to commit something idiotic, then you can trust them to manage the head references properly. However, if your company has some super paranoid and poorly considered policy, then it is an option.
We do not enforce this at GitHub and not only has it never been a problem, but it has helped us help people solve issues that they do have - accidentally committing files you really don't want in there, or code with a license you actually cannot use or something. With Git it's relatively easy to fix the repository and force push the update and let your collaborators know this needs to be done. With Mercurial... I honestly don't know how you can deal with that.
Furthermore, it doesn't actually lose the changes, it just removes the pointer to them, you can push the old pointer back very easily. So, if you think this is an entirely 'bad thing', then I feel you misunderstand what it really means.
It's funny you say that I'm "not understanding what it really means" because that was actually the point of my criticism of Git.
Maybe it's just me that's stupid, but that doesn't explain the million blog entries saying either Git Sucks because it's impossible to use, or that they've had a eureka breakthrough and actually Git Rocks but you just have to understand that [reams of random gibberish] is what you need to achieve simple task A. The latter type of blog post usually has at least two comments pointing out that what the blogger suggests is both wrong and dangerous and suggesting two conflicting solutions to the same problem.
Apparently it's not as bad as it used to be. Again my knowledge comes mostly from blogs but every couple of months I read that Git is no longer perversely and unusably obscure. The fact that its unnecessary complexity is now being used as a defence against criticism doesn't encourage me to think that anyone is actually going to finally fix the human factors of git anytime soon.
Maybe it's just me that's stupid, but that doesn't explain the million blog entries saying either Git Sucks because it's impossible to use, or that they've had a eureka breakthrough and actually Git Rocks but you just have to understand that [reams of random gibberish] is what you need to achieve simple task A. The latter type of blog post usually has at least two comments pointing out that what the blogger suggests is both wrong and dangerous and suggesting two conflicting solutions to the same problem.
Apparently it's not as bad as it used to be. Again my knowledge comes mostly from blogs but every couple of months I read that Git is no longer perversely and unusably obscure. The fact that its unnecessary complexity is now being used as a defence against criticism doesn't encourage me to think that anyone is actually going to finally fix the human factors of git anytime soon.
I have worked both with mercurial and git (3-5 developers).
Git has definitely more features, but there aren't useful that much. Things like rewriting history is often quite confusing and it is pretty easy to shoot yourself in the foot. It also got tons of quirks.
Personally I think that git is over-hyped. A lot of developers said to me how git is awesome, but it seems that they spent much more time maintaining code then on the other VCS/DVCS. Hg just work, it is easy to learn, gives much more meaningful error messages... and got all of the major advantages of DVCS, but it has much less fans then git.
So the question is whether you want to focus on developing an application and use DVCS as a tool. Or rather playing with your DVCS is a fun itself. First case pick Hg, second - git.
Note that my comment applies only for small teams. I have got absolutely no experience with big projects(> 30 developers, > 2 years) so YMMV in that case.
Git has definitely more features, but there aren't useful that much. Things like rewriting history is often quite confusing and it is pretty easy to shoot yourself in the foot. It also got tons of quirks.
Personally I think that git is over-hyped. A lot of developers said to me how git is awesome, but it seems that they spent much more time maintaining code then on the other VCS/DVCS. Hg just work, it is easy to learn, gives much more meaningful error messages... and got all of the major advantages of DVCS, but it has much less fans then git.
So the question is whether you want to focus on developing an application and use DVCS as a tool. Or rather playing with your DVCS is a fun itself. First case pick Hg, second - git.
Note that my comment applies only for small teams. I have got absolutely no experience with big projects(> 30 developers, > 2 years) so YMMV in that case.
Anecdotally...
Most of my friends and co-workers have switched to git for their local work (pushing back to SVN when working on a project that requires this). Since then I've seen more time spent tracking down and fixing weird version-control things than I ever did with SVN, or with hg (which I've been using).
I don't know if this is because one is genuinely more "easy" or more "powerful" than the other, or whether it's just the learning curve of a new workflow (I'm not really using the 'D' in 'DVCS' much, actually).
Most of my friends and co-workers have switched to git for their local work (pushing back to SVN when working on a project that requires this). Since then I've seen more time spent tracking down and fixing weird version-control things than I ever did with SVN, or with hg (which I've been using).
I don't know if this is because one is genuinely more "easy" or more "powerful" than the other, or whether it's just the learning curve of a new workflow (I'm not really using the 'D' in 'DVCS' much, actually).
Darn. I was really hoping they'd pick git, to help one dvcs win the stalemate and I would never have to become proficient in both :-)
Now google has probably put the balance back to a tie between the two systems- Git probably was in the lead before this announcement.
Now google has probably put the balance back to a tie between the two systems- Git probably was in the lead before this announcement.
I think the #1 reason is that like they mention git is a second class citizen on Windows. If git was more integrated with windows they probably would have chosen it.
I like git, Mercurial, Bazaar but my favorite recently is Mercurial. Both Python and Google Code switching to Mercurial. The funny thing is Mercurial might win because of this. Google code played a huge role in SVN becoming so popular.
Both Mercurial and Bazaar are Python based. Git is C based and written really for *nix in mind only.
I like git, Mercurial, Bazaar but my favorite recently is Mercurial. Both Python and Google Code switching to Mercurial. The funny thing is Mercurial might win because of this. Google code played a huge role in SVN becoming so popular.
Both Mercurial and Bazaar are Python based. Git is C based and written really for *nix in mind only.
> I think the #1 reason is that like they mention git is a second class citizen on Windows.
And the second reason is that git is downright slow over HTTP, and google code's built around using HTTP.
And the second reason is that git is downright slow over HTTP, and google code's built around using HTTP.
I was under the impression that competition was generally considered a good thing, especially when the products involved in this case are similar enough that it'd be easy to automate interoperation between them.
IMHO, the 2 products are too similar for the competition to be very advantageous.
The past has shown that all real future innovation in version control will come from new products, not established products... Five more years of Git vs. Hg is probably not going to help innovate version control systems.
The past has shown that all real future innovation in version control will come from new products, not established products... Five more years of Git vs. Hg is probably not going to help innovate version control systems.
I'm not so sure.
I see git vs. hg as a KDE vs. GNOME type thing -- similar products, yes, but with different underlying philosophies and presenting the same ideas in usefully different ways.
I see git vs. hg as a KDE vs. GNOME type thing -- similar products, yes, but with different underlying philosophies and presenting the same ideas in usefully different ways.
Given that I currently still have to deal with SVN and, god help us, CVS, I can't say I'm particularly afraid of Hg. Should I be?
Heck no. Check out the hgsubversion plugin for HG. It is getting pretty close to seamlessly hiding SVN as a parent of an HG clone. I've been using it for a few months on a large project (ca. 450k LOC, 8 years of history). You "hg clone svn+http://..." and then you can hg pull/push like normal. I haven't tried any major cross-branch merging -- I still do that in SVN at the moment -- but it works really well. I've got an HG SVN clone on my desktop at work, and a clone of that on my laptop.
I don't know about the HG/CVS possibilities, but I wouldn't be worried about DVCSes.
And, on an unrelated note, I'm really happy about Google's decision. I evaluated git a while ago, and I found it kludgy and awkward. A revision control system should stay out of my way and be a useful tool, not become a full-time job with an equivalent learning curve.
I don't know about the HG/CVS possibilities, but I wouldn't be worried about DVCSes.
And, on an unrelated note, I'm really happy about Google's decision. I evaluated git a while ago, and I found it kludgy and awkward. A revision control system should stay out of my way and be a useful tool, not become a full-time job with an equivalent learning curve.
Why would you be afraid?
I bet Google picked Mercurial because it was easier for them to hack on and adapt to their infrastructure. A "libgit" is on lots of people's wish list, but the official developers seem pretty happy with the hodgepodge of binaries.
Just read their announcement. They picked hg for two reasons:
1. Google Code is built around HTTP, Git sucks at talking HTTP (it's an order of magnitude slower than hg). On the other hand, HTTP is hg's first-class protocol. So hg's integration was simpler here.
2. Windows still is a first-class platform for mercurial, still isn't for git, and windows users are an important part of Google Code's clientele.
1. Google Code is built around HTTP, Git sucks at talking HTTP (it's an order of magnitude slower than hg). On the other hand, HTTP is hg's first-class protocol. So hg's integration was simpler here.
2. Windows still is a first-class platform for mercurial, still isn't for git, and windows users are an important part of Google Code's clientele.
The biggest draw in favor of git - especially for those people, who are already working with SVN or CVS - is the interoperability scripts for git.
git-svn is freaking brilliant and is so convenient a bridge that several people maintain their SVN checkouts as git repositories and eventually checkin to the central SVN repositories using git.
git-svn is freaking brilliant and is so convenient a bridge that several people maintain their SVN checkouts as git repositories and eventually checkin to the central SVN repositories using git.
I'm surprised there isn't more talk of Bazaar. It's awesome.
I'm not. It still lags behind in usability (even though they want this to be one of their strong points) and performance (which they promised to fix ever since 1.0). They also don't have any large projects actually using it.
Bazaar tries to be simple, but they currently have so many different repository formats and supported workflows that everything is a mess. Using one format on the local side, and a different format on the remote can cause a performance loss. Commands do different things in one repository than in another, depending on how it is set up. They have the weird 'a branch is a directory' thing, and using lightweight branches like in git is a mess. That, and something like 9 of the top 10 developers work for Canonical, so it seems there's just not much interest of the open source community. What happens if Canonical stops getting money from millionaires? Will Bazaar still be supported? Do you want your product to depend on that?
Bazaar tries to be simple, but they currently have so many different repository formats and supported workflows that everything is a mess. Using one format on the local side, and a different format on the remote can cause a performance loss. Commands do different things in one repository than in another, depending on how it is set up. They have the weird 'a branch is a directory' thing, and using lightweight branches like in git is a mess. That, and something like 9 of the top 10 developers work for Canonical, so it seems there's just not much interest of the open source community. What happens if Canonical stops getting money from millionaires? Will Bazaar still be supported? Do you want your product to depend on that?
"Bazaar tries to be simple, but they currently have so many different repository formats and supported workflows that everything is a mess."
Quoted.
That's the #1 reason I've switched to mercurial two years ago: a simple model that perfectly fits into my mind.
I realized something was wrong with bzr when I created a mindmap to understand its model and its commands... and that was two years ago, I don't even want to try and imagine how that mindmap would look today.
Quoted.
That's the #1 reason I've switched to mercurial two years ago: a simple model that perfectly fits into my mind.
I realized something was wrong with bzr when I created a mindmap to understand its model and its commands... and that was two years ago, I don't even want to try and imagine how that mindmap would look today.
It's probably awesome, in the same way that git and hg are awesome. But how does it compare to hg or git? What is the network performance? How easy is it to implement the network protocol, and add BigTable support for it?
What about comparing what the users want? It doesn't matter how good the product is if everyone wants something else. Or even better yet what are your users already using? I have seen several google code projects that all point to github for the code.
Is this because Linus gave a git talk at Google calling them stupid for relying on Subversion?
Joking aside... they don't talk too much about the development communities of the two systems, and it's more than likely that they will have to 1) hack the system to work with their infrastructure, and 2) may want to feed some stuff back, and perhaps hg is easier in that sense, being in Python. Also, while I don't know this, perhaps the authors are easier to work with than Linus, who is a very busy dude and extremely ... let's say ... sure of himself (which is mostly deserved).
[deleted]
1) Learning Curve. This section states that Git has more commands and is harder to learn. In fact, they both have about the same number of commands - run 'git' and 'hg' with no arguments and you'll see how similar the common commands listings are. Hg and Git both have 'plumbing' commands that can be used for lower level stuff (run 'hg debug' if you don't believe me) that are not meant to be used by normal users, but both systems have them. The documentation issue is pretty moot too - Git has tons of useful documentation and I feel the homepage (git-scm.org) is much easier to use and find helpful information on (though I could be biased because I created it). As to the 'command set is closer to SVN so people get confused less', I think that's actually unhelpful. Hg is not Subversion and thinking about it as a 'Subversion+' I think makes users even more confused when something doesn't work how it did in SVN. Now something didn't work right AND they have a faulty mental model of what it's supposed to be doing. Furthermore, the UI for Hg is not all roses and puppies - one of the first things you have to do, editing config files, has to be done manually and can be confusing and seemingly arbitrary. Both systems have good and bad points in UI and functionality, but unless you're basing your decision on the systems as they were two years ago, which this article seems to be, it's really difficult to effectively argue that Hg is really easier to use. For every thing someone can say is difficult or unintuitive in Git, I can list one for Hg. I have seen tons of people pick it up and be able to use it effectively in a single day. This is subjective hearsay, it is not a valid argument.
2) Windows Support. If you run TortoiseGit or Git Extensions, you will see that Git has moved ahead leaps and bounds in this department recently. Even the general MinGW port by itself works really well and has a nice installer.
3) Maintenance. They state that 'Git requires periodic maintenance of repositories (i.e. git-gc)' - this is just flat out untrue. Git runs this command automatically every once in a while - you do not have to do it yourself. This is actually pretty nice because it keeps your repository as small as possible, where Mercurials reflog format can bloat unnecessarily and there is no way to optimize it's disk usage.
4) History is Sacred. They say that "Git is perfectly happy to lose history.", which is incredibly untrue - in fact, it's pretty difficult to lose history in Git. They site that you can run '--force' on a push to overwrite history, but there are several ways to disable this on the server. To point out how little they seem to understand Git server concepts, they say: "It should be noted, however, that a custom Git server could be written to disallow the loss of data, so this advantage is minimal." All you have to do for this either a) add a simple pre-receive hook that simply doesn't allow non-fast-forward pushes, or b) run 'git config --system receive.denyNonFastforwards true' on the server, which will make Git ignore the '--force' client option. You don't have to write a "custom git server", you need to run one quick command.
I actually like parts of Hg. Given that Guido works there and there are a lot of python devs there and Hg has good smart http protocol, I'm sure it makes perfect sense to use it. However, spreading this sort of FUD about Git is not helpful to the DVCS ecosystem as a whole.