4 ms·

Mercurial isn't the terrible DVCS that people left for greener git pastures; indeed it's the opposite: GitHub is why git won, and people are still learning how

by nilved 13y ago

Mercurial isn't the terrible DVCS that people left for greener git pastures; indeed it's the opposite: GitHub is why git won, and people are still learning how terrible git is and how awesome Mercurial is. They don't "still use" Mercurial, they "still use" git. Mercurial has a great API. git has a terrible API. Mercurial is a joy to extend in Python. git is impossible to extend to any meaningful degree and is a terrible mess of Perl, shell script and C. git is a hack and Mercurial is the future.

yapcguy 13y ago
I use both. I dont think Git 'won' but it is more popular. I suspect many git users dont even know why they use git except because they were told to, they probably never tried hg or know anything about darcs, bitkeeper, etc.
- leobelle 13y ago
  I like git because it stores objects, not diffs and you can recover from almost anything with reflog.
  - anton_gogolev 13y ago
    > I like git because it stores objects, not diffs Now _that's_ a reason to pick a VCS! Would you drop Git if you found out that this is not true [1]? [1]: http://git-scm.com/book/en/Git-Internals-Packfiles http://git-scm.com/book/en/Git-Internals-Packfiles
    - tomlu 13y ago
      I see where he is coming from even if the wording is ambiguous. Git presents the abstraction of storing objects, and diffs are inferred. The exact implementation is beside the point.
      - tonfa 13y ago
        But then mercurial is the same, the abstraction is about file content, the diff compression is an internal detail of the storage format like packs.
        tomlu 13y ago
        Yeah for sure. Mercurial is great too. I was thinking of SVN which does store its commits as diffs, which makes it brittle (anyone that has tried to use the svn admin tools to rewrite the repository will know what I mean).
- sopooneo 13y ago
  I use Git because everyone else does. And I'm not ashamed of that; I think it's pragmatic. However, I think I would prefer if the crowd had converged on Mercurial instead.
- kyrra 13y ago
  But being more popular is a reason groups will pick it. See Emacs's discussion on moving away from BZR [0]. While there are some people that like HG, Git popularity brings some benefits with it. A larger user base and a large number of companies using it mean that there will be more investment in the tool. So there is a variety of companies that invest in it. There is a smaller chance development will stop on Git compared to HG. So basically the Emacs team concluded they don't want to be stuck with another BZR, and Git seems like a safer choice. A variety of companies have bet on HG, but decided they needed to support Git along side it to get more sales (Fog Creek and Atlassian). I feel like Github was the deciding tech that made Git the more popular code. There are a number of other companies supporting HG still, so it won't go away anytime soon, but it's hard to say if it'll be here as long as Git. [0] http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00005.html http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg000...
kyrra 13y ago
Git an Mercurial are so similar. You have to remember that Git, Mercurial, and Bazaar were all released within a month of one another to do basically the same thing (because BitKeeper took their licenses away from linux debs). They all have very similar concepts and try to solve the same problem in near the same way. Each of these DVCSs have stolen concepts from one another and there isn't a lot differentiating them. Sure, syntax and terminology differ, but they all end up working pretty similar to one another. You have tools like Kiln Harmony[0] that lets you use git/mercurial for the same repo (looks like it cross-commit between the 2). Git gives you all commands all at once, while Mercurial gives you just the functionality needed 90% of the time that can't really get you in trouble. Mercurial ships officially supported extensions with Mercurial that let you do history rewriting and other fun stuff that people are used to with git rebase. I'm more a fan of Mercurial's CLI syntax/terminology, but Git has really won the popularity contest at this point. If you ever have questions about Git usage, the question has probably already been asked and has a lot more people that know and enjoy it. Mercurial does have some advantages going for it still I believe. Being purely written in python makes it work a bit better on Windows. And as Facebook has said, it is easier to develop new plugins for Mercurial (at least given their skillset). I also like the Mercurial Largefile extension (if you have to deal with a lot of binary data). I know there are 3rd party modules like git-annex, but nothing officially part of Git. [0] http://blog.fogcreek.com/kiln-harmony-internals-the-basics/ http://blog.fogcreek.com/kiln-harmony-internals-the-basics/
the_mitsuhiko 13y ago
> Mercurial isn't the terrible DVCS that people left for greener git pastures; indeed it's the opposite: For everybody who does not like git there is one who does. I vastly prefer git over hg after having used hg for a few years and I did not regret switching a single bit.

by nilved 13y ago

yapcguy 13y ago

I use both. I dont think Git 'won' but it is more popular. I suspect many git users dont even know why they use git except because they were told to, they probably never tried hg or know anything about darcs, bitkeeper, etc.

leobelle 13y ago
I like git because it stores objects, not diffs and you can recover from almost anything with reflog.
- anton_gogolev 13y ago
  > I like git because it stores objects, not diffs Now _that's_ a reason to pick a VCS! Would you drop Git if you found out that this is not true [1]? [1]: http://git-scm.com/book/en/Git-Internals-Packfiles http://git-scm.com/book/en/Git-Internals-Packfiles
  - tomlu 13y ago
    I see where he is coming from even if the wording is ambiguous. Git presents the abstraction of storing objects, and diffs are inferred. The exact implementation is beside the point.
    - tonfa 13y ago
      But then mercurial is the same, the abstraction is about file content, the diff compression is an internal detail of the storage format like packs.
      - tomlu 13y ago
        Yeah for sure. Mercurial is great too. I was thinking of SVN which does store its commits as diffs, which makes it brittle (anyone that has tried to use the svn admin tools to rewrite the repository will know what I mean).
sopooneo 13y ago
I use Git because everyone else does. And I'm not ashamed of that; I think it's pragmatic. However, I think I would prefer if the crowd had converged on Mercurial instead.
kyrra 13y ago
But being more popular is a reason groups will pick it. See Emacs's discussion on moving away from BZR [0]. While there are some people that like HG, Git popularity brings some benefits with it. A larger user base and a large number of companies using it mean that there will be more investment in the tool. So there is a variety of companies that invest in it. There is a smaller chance development will stop on Git compared to HG. So basically the Emacs team concluded they don't want to be stuck with another BZR, and Git seems like a safer choice. A variety of companies have bet on HG, but decided they needed to support Git along side it to get more sales (Fog Creek and Atlassian). I feel like Github was the deciding tech that made Git the more popular code. There are a number of other companies supporting HG still, so it won't go away anytime soon, but it's hard to say if it'll be here as long as Git. [0] http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00005.html http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg000...

kyrra 13y ago

Git an Mercurial are so similar. You have to remember that Git, Mercurial, and Bazaar were all released within a month of one another to do basically the same thing (because BitKeeper took their licenses away from linux debs). They all have very similar concepts and try to solve the same problem in near the same way. Each of these DVCSs have stolen concepts from one another and there isn't a lot differentiating them. Sure, syntax and terminology differ, but they all end up working pretty similar to one another. You have tools like Kiln Harmony[0] that lets you use git/mercurial for the same repo (looks like it cross-commit between the 2). Git gives you all commands all at once, while Mercurial gives you just the functionality needed 90% of the time that can't really get you in trouble. Mercurial ships officially supported extensions with Mercurial that let you do history rewriting and other fun stuff that people are used to with git rebase. I'm more a fan of Mercurial's CLI syntax/terminology, but Git has really won the popularity contest at this point. If you ever have questions about Git usage, the question has probably already been asked and has a lot more people that know and enjoy it. Mercurial does have some advantages going for it still I believe. Being purely written in python makes it work a bit better on Windows. And as Facebook has said, it is easier to develop new plugins for Mercurial (at least given their skillset). I also like the Mercurial Largefile extension (if you have to deal with a lot of binary data). I know there are 3rd party modules like git-annex, but nothing officially part of Git. [0] http://blog.fogcreek.com/kiln-harmony-internals-the-basics/ http://blog.fogcreek.com/kiln-harmony-internals-the-basics/

the_mitsuhiko 13y ago

> Mercurial isn't the terrible DVCS that people left for greener git pastures; indeed it's the opposite: For everybody who does not like git there is one who does. I vastly prefer git over hg after having used hg for a few years and I did not regret switching a single bit.