Mercurial vs Git; it’s all in the branches
felipec.wordpress.com
felipec.wordpress.com
My personal Windows machine has Cygwin, MSYS (for MinGW), and MSVC's own command line (based on cmd.exe), so that I can use each of those three compilers for compatibility testing my projects. With msysGit my experience has not been good at all; patching git into each of the evironments always seems to require some manual work on my part, despite msysGit's claim that it can put just the git binaries on PATH.
So quite frankly, I do not think the current Windows situation for git is adequate, as it has (in my experience) integrated poorly with various command line environments.
That's not what I would recommend at all. There's no guarantee a project will resolve those issues or that new ones will crop up. Google was correct in choosing hg because it was the best choice at the time (back in 2008).
It looks like his only positive point are the branches, and then goes on to say, "The conclusion shouldn’t be that surprising; Git wins." I'd imagine hg being supported in Windows without requiring a third party install is a big plus.
I think the first comment puts it nicely: http://gitvsmercurial.com/
----------- edit -----------
It looks like the author had a discussion in the comments:
>My objective is to show why Git is superior. So if you care about your own performance, and the one of your project, the choice is obvious. One allows you to do many things, the other one doesn’t.
However, this contradicts his previous statement that the differences between the two are subtle and only proves his bias is heavily influencing his conclusion.
Also, Google probably figured the tool they chose would have a bright future considering Google's prominence. In hindsight, Github won the community over and pushed Git toward critical mass.
Exactly this. For me, the biggest reason for using Git was GitHub; I could have my code stored on their server and easily collaborate with my friends.
The author chooses one use-case of his liking and demonstrates how (in his opinion) git handles that use case far superior than hg. I remain unconvinced that git's handling is actually better and while that may be a common case for him, I have yet to meet that use case.
I know of at least one company that still uses cvs as VCS of their choice because it perfectly fits their use case, does exactly what's needed and does not introduce any artificial complexity. Probably pretty much any modern VCS rips CVS apart in terms of features and storage model, but I can understand their reasons. By the authors reasoning they should switch to git because it's clearly and demonstrable superior in all respects.
The message seems to be 'git's never going to really try to work your way; why not pretend you're using *nix?'
But that's a chicken and egg situation; you don't know what you are missing until after you try out. Oh, I don't "need" more memory, I don't "need" an SSD, I don't need a 1TB drive. But once you have them, you suddenly realize you can't live without them. And that's usually what happens when people realize how they can utilize git branches effectively.
You are free to disagree, but at worst, they are exactly the same, and at best, git branches are superior (and so far nobody has managed to demonstrate otherwise in the 160 comments in my blog). So, why would you pick anything else than git?
> You are free to disagree, but at worst, they are exactly the same, and at best, git branches are superior (and so far nobody has managed to demonstrate otherwise in the 160 comments in my blog). So, why would you pick anything else than git?
I actually have to admit that after reading the whole comment thread in your blog, I'm actually convinced that the HG folks won the argument. Since you're a git developer it's expected that your takeaway is a different one. It's probably not that you're biased, but you know the way git does things soo far better than anything else that this is the way you think and live and anything else is inferior.
However, my answer to your question is a different one: Different tasks require different tools. Limiting yourself to one tool based on one use case is not a good decision.
If I only need a simple use case and there's a choice of a tool that is technically superior, only with a complicated user interface and a tool that is technically inferior but with a simple user interface I loose the moment I pick the superior tool. A complicated user interface makes me memorize and learn more, making the whole handling more tedious and error prone than required. I'd pick the simpler tool any day if it fits. I'll go for the more elaborate one when the need shows itself. The tricky point is choosing the right tool, but that works both ways. A powerful tool may be dangerous as well and cost you a finger, hand or more. A simple tool well under your control may bring you much farther with less injuries.
For example: Have you ever tried teaching non-developers (i.E. designers) the full git user interface with all it's powers? I usually get about as far a the subset that's equivalent to what svn can do before they nod me off. Github's simple gui client that can only talk to github repositories is what most folks that I know need and are content with. So if that's all they need and all they use, why should they opt for a more complicated piece of software. To them it's all "oh, I can store stuff there" and I can actually related to that. They'd be happy with svn and they'll never move beyond that. The only reason they switched is because github offers such a nifty image comparison view.
Wrong. If SSDs are superior in every way, why do spin disks still exist? Because SSDs are way more expensive for the same size, and don't have as much storage.
And you are ignoring the point by focusing on SSDs and not the point being made.
> I actually have to admit that after reading the whole comment thread in your blog, I'm actually convinced that the HG folks won the argument.
Oh really? Can you point to the comment in which they answer to my challenge? Or do you feel that evidence is not important?
> However, my answer to your question is a different one: Different tasks require different tools. Limiting yourself to one tool based on one use case is not a good decision.
Fallacy of hasty generalization. Sometimes it's better to pick the tool depending on the job, sometimes you should specialize in a certain tool. For example, there's not much point in picking a different editor for different tasks.
A more succinct example is saying; limiting to one tool, your hands, is not a good decision. Well, you can use your feet for some tasks if you want, the rest of the world would prefer hands any time for most tasks.
> For example: Have you ever tried teaching non-developers (i.E. designers) the full git user interface with all it's powers? I usually get about as far a the subset that's equivalent to what svn can do before they nod me off.
Have you? And were they already familiar with SVN? That's the problem, you are not even aware you are making an assumption; that SVN is the natural way to to SCM, and thus mercurial's UI is good because it resembles SVN.
As I mentioned in my blog post; some people claim they find git easier to learn, particularly the ones that don't know SVN, or were tainted by crap like CVS. IOW; they don't relearn.
Well, I guess we're running in circles. My point was: I can swap a spindle disk of the same size with an ssd of the same size and reap all the benefits without changing anything beyond that. You can't swap tools that use different (if similar) underlying concepts in that way. (That's still oversimplifying in the case of disk.)
> Oh really? Can you point to the comment in which they answer to my challenge? Or do you feel that evidence is not important?
Yes, really. And evidence was provided by both sides and it all comes down to a judgement call, a personal estimate which feature or which mental model seems more preferrable to you. It's a bit like vi vs emacs. Both are certainly capable and do have demonstrable advantages over the other but in the end it's a matter of which feature matters most to you.
> A more succinct example is saying; limiting to one tool, your hands, is not a good decision. Well, you can use your feet for some tasks if you want, the rest of the world would prefer hands any time for most tasks.
Well. You do have a knack for flawed comparisons. It's like saying "Limiting yourself limiting to one tool, a screwdriver if you're trying to drive in screws is not a good decision. Well, you can always use a hammer for some screws, but the rest of the world would prefer using a screwdriver for most screws." My point is not "pick the least fitting tool for any task you find." but rather "have a sledgehammer and a carpenters hammer ready." You don't want the sledgehammer to hang up a picture, but you'd not want the carpenters hammer to drive in a pole either.
> Have you? And were they already familiar with SVN? That's the problem, you are not even aware you are making an assumption; that SVN is the natural way to to SCM, and thus mercurial's UI is good because it resembles SVN.
Yes I have. Multiple times. And some were familiar with svn and some where not. However, nowhere did I say that they preferred hg over git nor am I making any assumption that there even exists something such akin to a natural way to do SCM.
I argue that for their use cases the feature set of what svn can do is wholly sufficient. They don't do branching and they don't do merging since PSD files merge so awfully bad even with git. The couldn't care less about svn's need to hit the network for pretty much every operation since the central repository is inside the same gigbit LAN and will never move. They want mandatory locking in the repository for their word files so that person A can indicate "hey, I'm working on that document". And I hope we can agree that for the set of features that is supported by svn, svn offers the simpler mental model and also the simpler user interface. It does away with all that local repository and only knows a local working copy and a centralized remote storage. You can push changes to the remote and pull updates from there. And if that's all you ever need, svn might be the natural choice. Or maybe perforce. Or alienbrain. If your uses go beyond that, well, then it isn't. And then it's maybe git. Or darcs - which does have some very nifty features of it's own.
As a side note: mercurials UI is superior to git's not because it resembles svn's but for one singe major reason: It's consistent where git's is not.
Example: git uses the sometimes the full verb (git add, commit, ...) and sometimes an abbreviation (git rm). This probably stems from the fact that "rm" is the unix command to remove files and in line with what the usual unix developer would expect, but it's not internally consistent. HG always uses the full verb (hg add, hg remove). Git knows (add, remove, move) but not (copy). Git knows "git submodule add" which is a simple operation but the reverse is an arcane invocation that requires you to modify two config files and may as well trash your repository if executed wrong. None of this is related to svn or the svn user interface.
And what does that point has to do with anything?
> Yes, really. And evidence was provided by both sides and it all comes down to a judgement call, a personal estimate which feature or which mental model seems more preferrable to you.
Wrong. It's not a judgement call, I mentioned specifically for which cases git branching is superior, and I constructed a challenge to show that git is superior in that case and NOBODY answered the challenge. Conversely, NOBODY provided a case for the opposite; that mercurial's branching is superior in any case.
It's very simple; you can do more with git branching than with mercurial branching. Period.
> Well. You do have a knack for flawed comparisons. It's like saying "Limiting yourself limiting to one tool, a screwdriver if you're trying to drive in screws is not a good decision.
Completely irrelevant. You can't get out of the hasty generalization fallacy by pointing out a case in your favor. Yes, sometimes proficiency in more tools is better, but not ALWAYS. Just like yeah, in some cases black people like chicken, but not ALWAYS.
> The couldn't care less about svn's need to hit the network for pretty much every operation since the central repository is inside the same gigbit LAN and will never move.
Assumptions, assumptions, assumptions.
> As a side note: mercurials UI is superior to git's not because it resembles svn's but for one singe major reason: It's consistent where git's is not.
There have been calls for suggestions for improvement, including radical changes since years. NOBODY has ever suggested to replace 'rm' with 'remove'; it's not an issue.
If you want to talk about real consistency issues, how about branches vs bookmarks vs anonymous branches. In git they are all branches.
Actually, the word 'guarantee' is so strong, that in fact you don't have any guarantee that the mercurial project will fork, or implode, or even that the next financial crisis would turn the world into a post-apocalyptic one similar to Mad Max before any of that is relevant. You don't have a guarantee of anything.
That's why unlike you; I didn't talk about guarantees, but 'chances', and chances are: the most active and successful project (git) will solve its issues faster than anyone else. I have seen that time and time again.
And at the time I wrote the article, I didn't even need to speculate, because the issues Google pointed were actually SOLVED at that point in time. So, no, Google was not correct. In fact, not only wasn't Google correct in 2011 with the benefit of hindsight, they weren't correct in 2008 as I explained some of their arguments were invalid.
And I mentioned; support for Git was one of the most wanted features, and they eventually did it. Most likely the only real reason they did mercurial first, was not any that they stated, but the fact that it was written in Python, so it was easier to port to their server tools; they mentioned something like that as a reason for the delay for Git support in their issue tracker.
And Git doesn't require any third party install, so that's inaccurate.
And yes, I mentioned in my blog post that I was biased, however, I can be biased and arrive to the right conclusion. So far, after 160 comments, nobody has managed to show that mercurial branches are as powerful as git ones, which suggests that my conclusion was correct.
Feel free to try to prove otherwise in my blog post, comments are open, and prepare to be refuted, like everybody else has been.
GitHub "won" because the developers were not only innovative but they listened to their user base. BitBucket developers have, so far, just scoffed at my requests for changes to features that should be fundamentally different.
For example, the issues system. When you first hit the issues list it sorts by most recent date created; if I want to see the most critical tickets (sorted by priority) I have to click on the priority column; but wait, that first sorts it as least important first (wtf?) so I have to click it AGAIN to get the highest priority tickets.
I put in two support tickets on the matter, one asking for the default when hitting the page to be sort by priority (most critical first) so I can see WHAT IS MOST CRITICAL THAT NEEDS TO GET DONE NOW. If not the default, give a settings option so that I can set what the default to sort by could be! Their response? "Create a bookmark" - yeah, that's what I've done but I shouldn't have to do that. It's little shit like this that irks me about bbucket vs GitHub.
The second ticket has to do with that silliness that is sorting least important first when you first click on the column sort... Le sigh.
I still use it though because I prefer mercurial to git.
I still hate how the raw cli interface with tons of switches forces me to learn git's internals and storage model. Git advocates usually tell me "you need to know to unleash the powers of git" but actually, I'd rather prefer not to know and regard it as an opaque tool.
Compared to svn or hg the cli feels crude and not well thought over either. There's commands that accept the full verb (add, diff, checkout, clone), others that accept an abbreviation (rm, mv), but no (remove, move). I can set that up using aliases, I know. But why do I have to? Then there's add, move and remove, but no copy (which is "cp <file>; git add <file>). I often find myself typing the wrong incantation because there's a mismatch in how the commands are named. In that respect svn really shines in comparison.
As they say, simple things should be simple, complex things should be possible. Mercurial is the best of both worlds.
So no, you can't do the same, that's the whole point. If you think you can, you are most likely mistaken, but feel free to show how in the comments of the blog, and expect a prompt rebuttal.
He is right on one thing: the differences are mostly subtle, the most glaring one being whether history is allowed to be rewritten or not. In the end it all comes down to personal preferences, and my personal experience is strongly in favor of hg.
Was it obvious because he specifically notes it in the intro to the article?
Note: I’m a long-time advocate of Git, and a contributor to the project, so I am biased (but I hope my conclusions are not).
He failed to do so, but we couldn't know that without reading the article.
What I said is that they are basically the same, except for the handling of branches, not history rewriting as you suggest.
I assume you agree that they are basically the same, now, if you disagree that the handling of branches is superior in git, feel free to add a comment in my blog, but after 160 comments, nobody has managed to contradict that conclusion.
So no, nobody has managed to prove where exactly is the bias. It is possible that git is superior, and that's what the evidence suggests.
[1]: http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its...
That was not the case.
That's not even true, history is allowed to be rewritten in mercurial (mercurial-bundled extensions `rebase`, and `mq` as well as the standard `rollback` command do — or can be used to do — exactly that, and so do third-party extensions such as `histedit`), there's little difference on that point. The difference is the tendency to push for history-rewriting.
> but that's splitting hairs.
Not being completely and utterly wrong is "splitting hairs"?
Furthermore, it makes very little sense to criticize a tool with no basis in the tool's capabilities themselves but based merely on its community's suggestions, do you also criticize Python because its community recommends underscore_separated method names and you prefer camelCase? I'm not saying the community is not important, but mercurial itself, as a tool, has absolutely no hangup on history rewriting.
That aside, I've used both over the last 3 years (2 in git; 1 in hg) and although I prefer git, hg is a fantastic tool. I think the largest difference between the 2 is usability. I do believe hg is quite a bit easier to pick up. It does a really good job of, by default, making sure you don't shoot yourself in the foot and also keeps you further away from the 'nitty-gritty'. Git, on the other hand, allows you to do whatever you want and generally makes the assumption you always know what you're doing. The details are not very far down from the surface and it's easy to get yourself in trouble if you don't know what you're doing.
Personally I prefer git because I feel so close to the metal, but there's certainly a perfectly valid argument to choose hg over git.
And I didn't pick any example, as I clearly said; they are basically the same, the only real difference is in the way they deal with branches, and obviously, I concentrated on the difference.