4 ms·

Why? As a Git fan, someone's perspective on why they prefer Mercurial would be really interesting. What rocks about Mercurial?

eropple 15y ago
Your question is difficult to answer in the light in which you intended it, because it doesn't really apply to me. I am not so invested in my source control system to say it "rocks". It works for my purposes and maps nicely to my view of how to handle source code--it's less that Mercurial is awesome, it's that I find Git unpleasant to work with. I find Git over-engineered toward the wrong goals; while I don't doubt the development credentials of the Git developers, I think that too little time has been put into making developers' lives easier. Linus has said previously that speed was a priority for him, and that's great--for kernel sources, I'd definitely put a premium on speed. It appears, however, to come at a cost: Git has long struck me as extremely user-hostile. The documentation may have improved as of late (I haven't checked) but it was absolutely atrocious for a very long time. I find its interface unintuitive and nondiscoverable (and here hg-git could help, were it not for the cognitive dissonance of dealing with one against the other). And its Windows support, even today, is unacceptably poor given that I spend about 40% of my time working there. hg-git addresses some of the more cosmetic issues noted above that I could, if so inclined, deal with myself, but it doesn't really address deeper concerns I have with Git itself. There are also issues of philosophy involved--Git requires you to accept certain behaviors and the cultural encouragement of same, e.g. rewritable history, of which I'm very much not a fan. (You can rewrite a Mercurial history as well, but it requires going out of your way to do so and is not culturally accepted. "Rebase" exists, via extensions, but nobody uses it. And I much prefer it that way.) To me, Mercurial feels much more like its developers spent a bit more time thinking--looking at how a wider set of developers work, and building something that's comfortable to more people in less time. Git feels like its developers asked no questions at all and started hammering out what made sense to them. Which is fine when it maps to the way you think and the way you work, but it doesn't map to either for me. (I also tend to think that Git wouldn't be nearly as popular had it not been reflexively adopted by everyone and their brother because of Github--this isn't "waah, my tool of choice isn't popular!", but more of a simple observation. I think it succeeds more in spite of itself than anything.)
- dasil003 15y ago
  I don't think user-friendliness should be a primary goal for a version control system. The reason being that this is something we use day in and day out for years, so the importance of the learning curve is dwarfed by the power of the UI and the workflows it enables. When I switched from svn to git (and don't take this to mean I'm comparing svn to hg, because obviously hg is in git's league, not svn's), the learning curve was steep, but after 3 months of daily use I understood git's internals and what the various commands actually do infinitely better than I did after 5 years of using svn. In other words, I think git has an internal logic that allows it to fit into a small space in your brain once fully grokked. As to the rebase vs merge debate, I've already written about this (http://darwinweb.net/articles/the-case-for-git-rebase http://darwinweb.net/articles/the-case-for-git-rebase), but fundamentally my argument boils down to this: Having a linear history allows me to resolve historical bugs better than a history full of merge commits. If I run a bisect on a linear history I will always narrow down a bug to a single commit instead of potentially a merge commit with hundreds of commits behind it. Now, merge commits give you more information about the history, but when topic branches proliferate that information becomes very hard to make sense of anyway. With rebased commits I can still see when they were committed, so it's not as if there is no evidence of the actual development. Being able to see the exact state a particular commit was developed in is useful, but in my experience does not offset the hassle of a very messy history in solving bugs in the current state of the code base.
  - eropple 15y ago
    I do think that user-friendliness must be a primary goal for a VCS, because I have to get people who aren't hardcore, balls-to-the-wall programmers to use it if I need to store their data in my tree. Hg can be picked up by those folks in short order and requires no "grokking" beyond what you can read on Spolsky's HG Init in half an hour minutes. (I have in the past worked with designers who were wholly out of their element with anything beyond HTML, CSS, and very simple jQuery-backed JavaScript; expecting them to "grok" their VCS was more of a demand than I wanted to make because I'd have had to teach them.) And, to be honest, I think having to "grok" your VCS is only slightly less ridiculous of a requirement for software to force upon its user than is having to "grok" your text editor. Similarly, is why I don't use vim and do use Sublime Text. I don't think git's internal logic is more meaningfully flexible than hg's, but, IMO, hg provides a vastly more user-friendly experience. I could be wrong on this, but assuming I'm not--if you can get both, why not get both? =) (And don't get me wrong--I realize the arguments for rebase as opposed to merge. I reject them for my own projects for reasons that are largely subjective, and prefer a system where they are difficult and not commonplace. It's totally a matter of taste, but one I do feel somewhat strongly about and is what I'm referring to by disagreements in philosophy.)

eropple 15y ago

Your question is difficult to answer in the light in which you intended it, because it doesn't really apply to me. I am not so invested in my source control system to say it "rocks". It works for my purposes and maps nicely to my view of how to handle source code--it's less that Mercurial is awesome, it's that I find Git unpleasant to work with. I find Git over-engineered toward the wrong goals; while I don't doubt the development credentials of the Git developers, I think that too little time has been put into making developers' lives easier. Linus has said previously that speed was a priority for him, and that's great--for kernel sources, I'd definitely put a premium on speed. It appears, however, to come at a cost: Git has long struck me as extremely user-hostile. The documentation may have improved as of late (I haven't checked) but it was absolutely atrocious for a very long time. I find its interface unintuitive and nondiscoverable (and here hg-git could help, were it not for the cognitive dissonance of dealing with one against the other). And its Windows support, even today, is unacceptably poor given that I spend about 40% of my time working there. hg-git addresses some of the more cosmetic issues noted above that I could, if so inclined, deal with myself, but it doesn't really address deeper concerns I have with Git itself. There are also issues of philosophy involved--Git requires you to accept certain behaviors and the cultural encouragement of same, e.g. rewritable history, of which I'm very much not a fan. (You can rewrite a Mercurial history as well, but it requires going out of your way to do so and is not culturally accepted. "Rebase" exists, via extensions, but nobody uses it. And I much prefer it that way.) To me, Mercurial feels much more like its developers spent a bit more time thinking--looking at how a wider set of developers work, and building something that's comfortable to more people in less time. Git feels like its developers asked no questions at all and started hammering out what made sense to them. Which is fine when it maps to the way you think and the way you work, but it doesn't map to either for me. (I also tend to think that Git wouldn't be nearly as popular had it not been reflexively adopted by everyone and their brother because of Github--this isn't "waah, my tool of choice isn't popular!", but more of a simple observation. I think it succeeds more in spite of itself than anything.)

dasil003 15y ago
I don't think user-friendliness should be a primary goal for a version control system. The reason being that this is something we use day in and day out for years, so the importance of the learning curve is dwarfed by the power of the UI and the workflows it enables. When I switched from svn to git (and don't take this to mean I'm comparing svn to hg, because obviously hg is in git's league, not svn's), the learning curve was steep, but after 3 months of daily use I understood git's internals and what the various commands actually do infinitely better than I did after 5 years of using svn. In other words, I think git has an internal logic that allows it to fit into a small space in your brain once fully grokked. As to the rebase vs merge debate, I've already written about this (http://darwinweb.net/articles/the-case-for-git-rebase http://darwinweb.net/articles/the-case-for-git-rebase), but fundamentally my argument boils down to this: Having a linear history allows me to resolve historical bugs better than a history full of merge commits. If I run a bisect on a linear history I will always narrow down a bug to a single commit instead of potentially a merge commit with hundreds of commits behind it. Now, merge commits give you more information about the history, but when topic branches proliferate that information becomes very hard to make sense of anyway. With rebased commits I can still see when they were committed, so it's not as if there is no evidence of the actual development. Being able to see the exact state a particular commit was developed in is useful, but in my experience does not offset the hassle of a very messy history in solving bugs in the current state of the code base.
- eropple 15y ago
  I do think that user-friendliness must be a primary goal for a VCS, because I have to get people who aren't hardcore, balls-to-the-wall programmers to use it if I need to store their data in my tree. Hg can be picked up by those folks in short order and requires no "grokking" beyond what you can read on Spolsky's HG Init in half an hour minutes. (I have in the past worked with designers who were wholly out of their element with anything beyond HTML, CSS, and very simple jQuery-backed JavaScript; expecting them to "grok" their VCS was more of a demand than I wanted to make because I'd have had to teach them.) And, to be honest, I think having to "grok" your VCS is only slightly less ridiculous of a requirement for software to force upon its user than is having to "grok" your text editor. Similarly, is why I don't use vim and do use Sublime Text. I don't think git's internal logic is more meaningfully flexible than hg's, but, IMO, hg provides a vastly more user-friendly experience. I could be wrong on this, but assuming I'm not--if you can get both, why not get both? =) (And don't get me wrong--I realize the arguments for rebase as opposed to merge. I reject them for my own projects for reasons that are largely subjective, and prefer a system where they are difficult and not commonplace. It's totally a matter of taste, but one I do feel somewhat strongly about and is what I'm referring to by disagreements in philosophy.)