4 ms·

I think the question betrays the authors bias and assumes too much; by claiming that "almost every article comparing mercurial and git" and saying "it seems lik

I think the question betrays the authors bias and assumes too much; by claiming that "almost every article comparing mercurial and git" and saying "it seems like Mercurial has a better command line UX", the author is obviously a fan of Mercurial; neither of those points seem to be true. While I can understand the sour grapes at seeing an "inferior" technology win, it's not that clear cut. I haven't used Mercurial enough to really compare, but I can say that most of the supposed "advantages" of Mercurial versus Git seem moot to me. The CLI "UX" differences are negligible, it doesn't matter what languages they are written in, and git is ultimately more flexible due to less dogmatism. Perhaps the question should be closed with an "already answered" link to this: http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast http://stackoverflow.com/questions/1598759/git-and-mercurial... Edit: Followup with some more links: http://schacon.github.com/2008/11/24/on-mercurial.html http://schacon.github.com/2008/11/24/on-mercurial.html http://tomayko.com/writings/the-thing-about-git http://tomayko.com/writings/the-thing-about-git http://blogs.atlassian.com/2012/03/git-vs-mercurial-why-git/ http://blogs.atlassian.com/2012/03/git-vs-mercurial-why-git/

wyuenho 14y ago
You said you haven't used Mercurial much to really compare, and then you compared, and said git is more flexible, and the CLI difference are negligible. So I think you definitely have a bias towards git. I use Mercurial and Git every day, and I can tell you there's a marked difference between the usability of Mercurial and Git. Git would become totally unusable if it weren't for stackoverflow and google, while I can figure everything out just from Mercurial's short and sweet help manuals.
- npsimons 14y ago
  I admit I'm biased towards git; but, unlike the original question poster, I can link to articles backing up my assessment that the UX differences between Git and Mercurial are negligible at best, and most likely any perceived differences are highly subjective.
  - alwillis 14y ago
    Actually, the UX differences aren't negligible; from Google's assessment of Mercurial and Git. Complexity has a cost in terms of time, mistakes made, training, that can be quantified. From Google's assessment of Mercurial and Git: http://code.google.com/p/support/wiki/DVCSAnalysis http://code.google.com/p/support/wiki/DVCSAnalysis Learning Curve. Git has a steeper learning curve than Mercurial due to a number of factors. Git has more commands and options, the volume of which can be intimidating to new users. Mercurial's documentation tends to be more complete and easier for novices to read. Mercurial's terminology and commands are also a closer to Subversion and CVS, making it familiar to people migrating from those systems.
Niten 14y ago
I use both extensively (git for most personal projects, Mercurial at work), so I feel like chiming in here. I really do think that Mercurial's user interface is easier for beginners to pick up, and more difficult to shoot oneself in the foot with. It's the little things, like the fact that Mercurial's push and pull commands do exactly the opposite of one another, that hg clone/pull URLs are identical to what you type into a web browser to browse the repo, and the ease of dealing with Mercurial "bare" repositories (hg up -r null) for mirroring and backup purposes. And the way Mercurial's command-line interface strongly discourages one from modifying history; it makes it harder for things to get messed up on a small team coordinating with a shared-access repo. Yes, I know git has the reflog, but in general people seem to have much fewer "OMG WHAT JUST HAPPENED TO MY BRANCH" moments with Mercurial than with git. That (along with mq, which provided a unique solution to our team's needs) was the major reason I chose Mercurial over git at work. If we're going to brandish about the term "UX" here, then I'd say Mercurial definitely has a better "UX" than git. But Mercurial has pain points, too. The biggest one, in my opinion, is the way branches work: Mercurial started out with named branches, which it seems the community has recognized as a mistake, and has moved to replace with git-style branches (called "bookmarks" in Mercurial land). These work better, but there are still some drawbacks: for one thing, Mercurial lacks the notion of a "remote", so unlike in git your local bookmarks and remote bookmarks have to share the same namespace. This leads to counter-intuitive behavior when it comes to synchronizing bookmarks with a remote server, and often you'll find that bookmarks aren't necessarily updated when you'd expect them to be. Additionally, the notion of a "tip" makes working with feature branches frustrating, because by default Mercurial will check out from whatever branch was pushed to most recently, rather than a de-facto standard "master" as in git. Hand in hand with this complaint, by default Mercurial will want to push all your changesets, not just those under your current working bookmark, so you have to constantly specify e.g. "hg push -r master" to keep from pushing local throw-away branches. And it's not easy to delete local throw-away branches if you decide you don't want them (the downside of Mercurials aversion toward history modification), so one generally winds up using a separately-cloned repo for temporary work, which is unfortunate in contrast with git. Mercurial and git are both great, efficient, high-performance tools. But if I had to generalize, I'd say that Mercurial is better for beginners and for "enterprisey" usage, whereas git, despite its interface inconsistencies, can be more powerful once you fully understand it and its data model (but only if you aren't working primarily on Windows, and don't need Mercurial Queues).

wyuenho 14y ago

You said you haven't used Mercurial much to really compare, and then you compared, and said git is more flexible, and the CLI difference are negligible. So I think you definitely have a bias towards git. I use Mercurial and Git every day, and I can tell you there's a marked difference between the usability of Mercurial and Git. Git would become totally unusable if it weren't for stackoverflow and google, while I can figure everything out just from Mercurial's short and sweet help manuals.

npsimons 14y ago
I admit I'm biased towards git; but, unlike the original question poster, I can link to articles backing up my assessment that the UX differences between Git and Mercurial are negligible at best, and most likely any perceived differences are highly subjective.
- alwillis 14y ago
  Actually, the UX differences aren't negligible; from Google's assessment of Mercurial and Git. Complexity has a cost in terms of time, mistakes made, training, that can be quantified. From Google's assessment of Mercurial and Git: http://code.google.com/p/support/wiki/DVCSAnalysis http://code.google.com/p/support/wiki/DVCSAnalysis Learning Curve. Git has a steeper learning curve than Mercurial due to a number of factors. Git has more commands and options, the volume of which can be intimidating to new users. Mercurial's documentation tends to be more complete and easier for novices to read. Mercurial's terminology and commands are also a closer to Subversion and CVS, making it familiar to people migrating from those systems.

Niten 14y ago

I use both extensively (git for most personal projects, Mercurial at work), so I feel like chiming in here. I really do think that Mercurial's user interface is easier for beginners to pick up, and more difficult to shoot oneself in the foot with. It's the little things, like the fact that Mercurial's push and pull commands do exactly the opposite of one another, that hg clone/pull URLs are identical to what you type into a web browser to browse the repo, and the ease of dealing with Mercurial "bare" repositories (hg up -r null) for mirroring and backup purposes. And the way Mercurial's command-line interface strongly discourages one from modifying history; it makes it harder for things to get messed up on a small team coordinating with a shared-access repo. Yes, I know git has the reflog, but in general people seem to have much fewer "OMG WHAT JUST HAPPENED TO MY BRANCH" moments with Mercurial than with git. That (along with mq, which provided a unique solution to our team's needs) was the major reason I chose Mercurial over git at work. If we're going to brandish about the term "UX" here, then I'd say Mercurial definitely has a better "UX" than git. But Mercurial has pain points, too. The biggest one, in my opinion, is the way branches work: Mercurial started out with named branches, which it seems the community has recognized as a mistake, and has moved to replace with git-style branches (called "bookmarks" in Mercurial land). These work better, but there are still some drawbacks: for one thing, Mercurial lacks the notion of a "remote", so unlike in git your local bookmarks and remote bookmarks have to share the same namespace. This leads to counter-intuitive behavior when it comes to synchronizing bookmarks with a remote server, and often you'll find that bookmarks aren't necessarily updated when you'd expect them to be. Additionally, the notion of a "tip" makes working with feature branches frustrating, because by default Mercurial will check out from whatever branch was pushed to most recently, rather than a de-facto standard "master" as in git. Hand in hand with this complaint, by default Mercurial will want to push all your changesets, not just those under your current working bookmark, so you have to constantly specify e.g. "hg push -r master" to keep from pushing local throw-away branches. And it's not easy to delete local throw-away branches if you decide you don't want them (the downside of Mercurials aversion toward history modification), so one generally winds up using a separately-cloned repo for temporary work, which is unfortunate in contrast with git. Mercurial and git are both great, efficient, high-performance tools. But if I had to generalize, I'd say that Mercurial is better for beginners and for "enterprisey" usage, whereas git, despite its interface inconsistencies, can be more powerful once you fully understand it and its data model (but only if you aren't working primarily on Windows, and don't need Mercurial Queues).