4 ms·

>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

by 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.
- stevecooperorg 15y ago
  For me, the big missing use case is using it on Windows. It feels like git actively hates the Windows developer. Install mysygit on a windows box and the recommended option is to use a bash shell. A bash shell on a windows machine. The message seems to be 'git's never going to really try to work your way; why not pretend you're using *nix?'
- felipec 15y ago
  I did not dismiss any use-case. As I said; they are mostly the same. So, if you don't need complex use of branches, you would be fine with either git or mercurial, obviously. 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?
  - Xylakant 15y ago
    This is a false assumption and a flawed comparison. An SSD has the same external interface as a spindle disk. It does have does have different internal properties though that make it superior in almost all use cases though. > 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.
felipec 15y ago
There's no guarantee that new issues will crop up? Well, that's an argument against mercurial as well, is it not? Hell, it's an argument against anything, so I wonder how you can consider it an argument at all. 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.

by ceol 15y ago

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.

stevecooperorg 15y ago
For me, the big missing use case is using it on Windows. It feels like git actively hates the Windows developer. Install mysygit on a windows box and the recommended option is to use a bash shell. A bash shell on a windows machine. The message seems to be 'git's never going to really try to work your way; why not pretend you're using *nix?'
felipec 15y ago
I did not dismiss any use-case. As I said; they are mostly the same. So, if you don't need complex use of branches, you would be fine with either git or mercurial, obviously. 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?
- Xylakant 15y ago
  This is a false assumption and a flawed comparison. An SSD has the same external interface as a spindle disk. It does have does have different internal properties though that make it superior in almost all use cases though. > 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.

felipec 15y ago

There's no guarantee that new issues will crop up? Well, that's an argument against mercurial as well, is it not? Hell, it's an argument against anything, so I wonder how you can consider it an argument at all. 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.