6 ms·

Mercurial vs Git; it’s all in the branches

14 points by JayInt 15y ago

BerislavLopac 15y ago
To me, it's obvious that the author has entered the comparison with a very strong git bias, so it is only naturally that git won eventually. 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.
- parfe 15y ago
  >To me, it's obvious that the author has entered the comparison with a very strong git bias, so it is only naturally that git won eventually. 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).
  - eipipuz 15y ago
    That's not obvious. He clearly says he hopes his conclusions would go beyond his bias. He failed to do so, but we couldn't know that without reading the article.
  - BerislavLopac 15y ago
    LOL no, I missed that one. But the sibling is correct, the author failed.
    - felipec 15y ago
      Saying "the author failed" is easy. Presenting a case that demonstrates so is not. 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.
  - eslaught 15y ago
    The author seems to contradict himself in a comment[1]: My objective is to show why Git is superior. (Thanks to [2] for noticing.) [1]: http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches/#comment-5773 http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its... [2]: http://news.ycombinator.com/item?id=3437677 http://news.ycombinator.com/item?id=3437677
    - felipec 15y ago
      It's not a contradiction. Note the word why. If in the analysis it turns out I fail to show that git is indeed superior, I would have to agree mercurial is superior, or they are equal. That was not the case.
- masklinn 15y ago
  > the most glaring one being whether history is allowed to be rewritten or not. 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.
  - BerislavLopac 15y ago
    OK, "supposed" might be a better choice than "allowed"; but that's splitting hairs.
    - masklinn 15y ago
      No, "supposed" is almost as incorrect, mq is there in the standard distribution and most of its job is history rewriting (the mere act of popping a patch effectively rewrites history). `rebase`'s sole job is rewriting history. > 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.
      - BerislavLopac 15y ago
        I'm sorry? Which tool was I criticizing exactly?
- stevecooperorg 15y ago
  Yeah, this wasn't a straight comparison, but an act of apologetics.
yeswecan 15y ago
Let us not forget that GitHub is a major reason why people choose Git. If Bitbucket (or a hypothetical HgHub) had taken the larger market share first, we'd likely see more projects using Hg than Git.
- merijnv 15y ago
  I don't see how that factors in? I've been playing with GitHub a bit and I use hg. I just use the hggit extension the github guys wrote to interact with git and GitHub.
  - rcthompson 15y ago
    Yes, now you can use hg on GitHub just fine, but hggit didn't exist when GitHub got big.
- Ixiaus 15y ago
  I love hg, and bitbucket is the best we've got - but man, the developers at BitBucket have their heads stuck in so deep in the sand!!! 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.
  - 15y ago
ceol 15y ago
>My recommendation to other people facing similar decisions is to choose the project that has a brighter future, chances are the “disadvantages” you see in the present would be resolved soon enough. 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/ 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.
- ChrisLTD 15y ago
  "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." 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.
  - ceol 15y ago
    >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.
- Xylakant 15y ago
  I rather dislike how the author dismisses the fact that other people have other use-cases. 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.
eslaught 15y ago
I find it strange that he calls msysGit a good solution on Windows. 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.
- andrewflnr 15y ago
  That's strange. When I installed it a couple summers ago on Vista, it Just Worked. I didn't have Cygwin. Maybe a conflict?
deleted 15y ago
[deleted]
eipipuz 15y ago
Felipe Contreras, do you really not see your bias at selecting the example you chose? Paragraphs before you mention how in Mercurial "History is Sacred" then you push for that.
- felipec 15y ago
  I did not mention "history is sacred", Google did, in his analysis. 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.
lol_hn 15y ago
hn's gone down the shitter if posts like this make it to the front page. no, no one outside of this fucking filter bubble gives a shit which one's better at arcane crap no reasonable person would care about. people who actually get shit done just do so without writing long "OMG I AM TEH BIAS BUT THIS HAS NO BIAS, I PROMISE" blog posts about it. also, lol @ him thinking msysgit works. it'd almost be cute if git-tards weren't so annoying. not surprising though given how deeply the git butt plug's shoved up their asses
natmaster 15y ago
Mercurial having an extension to make their branches like git is exactly why Mercurial is superior. I love git branches, but everything else about it is worse, but that's OK because I just use the extension like everyone else. Mercurial has great extensibility, which means if you need to do anything not simple, it lets you. As they say, simple things should be simple, complex things should be possible. Mercurial is the best of both worlds.
- felipec 15y ago
  No, there's no extension in mercurial that makes branches behave like git branches. That is clear in the 160 comments where I even created a challenge for anyone to try to do the same in mercurial, and curiously, people have criticized my videos, scripts, and every little thing possible, but none have actually shown how it's possible to do the same in mercurial. 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.
198d 15y ago
This was a really bad comparison/argument for git. Anyone actually trying to decide between the two should just forget everything you've read and start with a different source. 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.
Uchikoma 15y ago
Blog posts that use "crush" should not be taken serious.

14 points by JayInt 15y ago

To me, it's obvious that the author has entered the comparison with a very strong git bias, so it is only naturally that git won eventually. 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.

parfe 15y ago
>To me, it's obvious that the author has entered the comparison with a very strong git bias, so it is only naturally that git won eventually. 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).
- eipipuz 15y ago
  That's not obvious. He clearly says he hopes his conclusions would go beyond his bias. He failed to do so, but we couldn't know that without reading the article.
- BerislavLopac 15y ago
  LOL no, I missed that one. But the sibling is correct, the author failed.
  - felipec 15y ago
    Saying "the author failed" is easy. Presenting a case that demonstrates so is not. 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.
- eslaught 15y ago
  The author seems to contradict himself in a comment[1]: My objective is to show why Git is superior. (Thanks to [2] for noticing.) [1]: http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches/#comment-5773 http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its... [2]: http://news.ycombinator.com/item?id=3437677 http://news.ycombinator.com/item?id=3437677
  - felipec 15y ago
    It's not a contradiction. Note the word why. If in the analysis it turns out I fail to show that git is indeed superior, I would have to agree mercurial is superior, or they are equal. That was not the case.
masklinn 15y ago
> the most glaring one being whether history is allowed to be rewritten or not. 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.
- BerislavLopac 15y ago
  OK, "supposed" might be a better choice than "allowed"; but that's splitting hairs.
  - masklinn 15y ago
    No, "supposed" is almost as incorrect, mq is there in the standard distribution and most of its job is history rewriting (the mere act of popping a patch effectively rewrites history). `rebase`'s sole job is rewriting history. > 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.
    - BerislavLopac 15y ago
      I'm sorry? Which tool was I criticizing exactly?
stevecooperorg 15y ago
Yeah, this wasn't a straight comparison, but an act of apologetics.

yeswecan 15y ago

Let us not forget that GitHub is a major reason why people choose Git. If Bitbucket (or a hypothetical HgHub) had taken the larger market share first, we'd likely see more projects using Hg than Git.

merijnv 15y ago
I don't see how that factors in? I've been playing with GitHub a bit and I use hg. I just use the hggit extension the github guys wrote to interact with git and GitHub.
- rcthompson 15y ago
  Yes, now you can use hg on GitHub just fine, but hggit didn't exist when GitHub got big.
Ixiaus 15y ago
I love hg, and bitbucket is the best we've got - but man, the developers at BitBucket have their heads stuck in so deep in the sand!!! 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.
- 15y ago

ceol 15y ago

>My recommendation to other people facing similar decisions is to choose the project that has a brighter future, chances are the “disadvantages” you see in the present would be resolved soon enough. 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/ 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.

ChrisLTD 15y ago
"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." 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.
- ceol 15y ago
  >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.
Xylakant 15y ago
I rather dislike how the author dismisses the fact that other people have other use-cases. 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.

eslaught 15y ago

I find it strange that he calls msysGit a good solution on Windows. 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.

andrewflnr 15y ago
That's strange. When I installed it a couple summers ago on Vista, it Just Worked. I didn't have Cygwin. Maybe a conflict?

deleted 15y ago

[deleted]

eipipuz 15y ago

Felipe Contreras, do you really not see your bias at selecting the example you chose? Paragraphs before you mention how in Mercurial "History is Sacred" then you push for that.

felipec 15y ago
I did not mention "history is sacred", Google did, in his analysis. 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.

lol_hn 15y ago

hn's gone down the shitter if posts like this make it to the front page. no, no one outside of this fucking filter bubble gives a shit which one's better at arcane crap no reasonable person would care about. people who actually get shit done just do so without writing long "OMG I AM TEH BIAS BUT THIS HAS NO BIAS, I PROMISE" blog posts about it. also, lol @ him thinking msysgit works. it'd almost be cute if git-tards weren't so annoying. not surprising though given how deeply the git butt plug's shoved up their asses

natmaster 15y ago

Mercurial having an extension to make their branches like git is exactly why Mercurial is superior. I love git branches, but everything else about it is worse, but that's OK because I just use the extension like everyone else. Mercurial has great extensibility, which means if you need to do anything not simple, it lets you. As they say, simple things should be simple, complex things should be possible. Mercurial is the best of both worlds.

felipec 15y ago
No, there's no extension in mercurial that makes branches behave like git branches. That is clear in the 160 comments where I even created a challenge for anyone to try to do the same in mercurial, and curiously, people have criticized my videos, scripts, and every little thing possible, but none have actually shown how it's possible to do the same in mercurial. 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.

198d 15y ago

This was a really bad comparison/argument for git. Anyone actually trying to decide between the two should just forget everything you've read and start with a different source. 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.

Uchikoma 15y ago

Blog posts that use "crush" should not be taken serious.