15 ms·

Agreed. It was a version control system for humans. Unfortunately the Hg people decided that the only stable interface would be the CLI, which made it infeasibl

Agreed. It was a version control system for humans. Unfortunately the Hg people decided that the only stable interface would be the CLI, which made it infeasible to build the likes of GitHub around Hg, and GitHub (not Git itself) is what drove Git's success.

andrewshadura 5y ago
> Unfortunately the Hg people decided that the only stable interface would be the CLI Citation needed for this. Mercurial has the best VCS GUI I have ever seen, TortoiseHg. And there are quite a few web UIs supporting Mercurial, namely Kallithea and GitLab’s fork heptapod.net.
- throwaway894345 5y ago
  I suspect you're confusing API with (G)UI, but in any case here's the citation you requested: https://www.mercurial-scm.org/wiki/MercurialApi https://www.mercurial-scm.org/wiki/MercurialApi > Mercurial's internals are continually evolving to be simpler, more consistent, and more powerful, a process we hope will continue for the foreseeable future. Unfortunately, this process means we will regularly be changing interfaces in ways that break third-party code in various (mostly minor) ways. For the vast majority of third party code, the best approach is to use Mercurial's published, documented, and stable API: the command line interface.
theamk 5y ago
Can we stop with "github" narrative? I remember choosing git vs hg back when github wasn't a thing yet. We chose git on its own merits - it was much faster and had much better support for editing commits (it mattered for our code review processs). I am sure our org was not the only one. (FWIW, I think hg may have caught up in those areas.. But this is too late now.)
- throwaway894345 5y ago
  Well, I don't think it's mere "narrative". I'm sure Git has its merits--performance, for example--but I seriously doubt this factored into most orgs' calculus considering most orgs probably wouldn't have hit any serious performance issues with hg. I strongly suspect that Git's popularity has a lot more to do with GitHub (and to a lesser extent, the popularity of the Linux kernel) than it did to any actual merit, but I don't think there's any evidence one way or another.
  - christophilus 5y ago
    Mercurial had its own GitHub, though. Was it bitbucket? I don’t remember, but it had an equivalent, I think. I really think Linux and performance was a key factor. Edit: I preferred hg, too, for the record.
    - throwaway894345 5y ago
      BitBucket eventually came to support Mercurial (in addition to Git and maybe others) but it was quite a long time after GitHub had been on the scene.
      - code_biologist 5y ago
        You misremember: The version control software market has evolved a lot since Bitbucket began in 2008. When we launched, centralized version control was the norm and we only supported Mercurial repos. https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket https://bitbucket.org/blog/sunsetting-mercurial-support-in-b... Github was launched in April 2008 [1]. Bitbucket is harder to find, but was definitely around by June 2008 [2]. Mercurial vs git was definitely the defining difference between the two initially, though the Rails ecosystem exploding onto Github made a huge adoption difference. git being faster + built in support for rebasing was big was well. [1] https://web.archive.org/web/20160409191635/http://www.startlin.es/timelines/github/ https://web.archive.org/web/20160409191635/http://www.startl... [2] https://web.archive.org/web/20110317200833/http://code.djangoproject.com/wiki/DjangoSuccessStoryBitbucket https://web.archive.org/web/20110317200833/http://code.djang...
seanw444 5y ago
Sourcehut (https://sr.ht https://sr.ht) seems to have support for Hg projects, though I've never tried it.
- throwaway894345 5y ago
  Probably, but the git vs hg debate was definitely settled by the time sr.ht hit the scene.

andrewshadura 5y ago

> Unfortunately the Hg people decided that the only stable interface would be the CLI Citation needed for this. Mercurial has the best VCS GUI I have ever seen, TortoiseHg. And there are quite a few web UIs supporting Mercurial, namely Kallithea and GitLab’s fork heptapod.net.

throwaway894345 5y ago
I suspect you're confusing API with (G)UI, but in any case here's the citation you requested: https://www.mercurial-scm.org/wiki/MercurialApi https://www.mercurial-scm.org/wiki/MercurialApi > Mercurial's internals are continually evolving to be simpler, more consistent, and more powerful, a process we hope will continue for the foreseeable future. Unfortunately, this process means we will regularly be changing interfaces in ways that break third-party code in various (mostly minor) ways. For the vast majority of third party code, the best approach is to use Mercurial's published, documented, and stable API: the command line interface.

theamk 5y ago

Can we stop with "github" narrative? I remember choosing git vs hg back when github wasn't a thing yet. We chose git on its own merits - it was much faster and had much better support for editing commits (it mattered for our code review processs). I am sure our org was not the only one. (FWIW, I think hg may have caught up in those areas.. But this is too late now.)

throwaway894345 5y ago
Well, I don't think it's mere "narrative". I'm sure Git has its merits--performance, for example--but I seriously doubt this factored into most orgs' calculus considering most orgs probably wouldn't have hit any serious performance issues with hg. I strongly suspect that Git's popularity has a lot more to do with GitHub (and to a lesser extent, the popularity of the Linux kernel) than it did to any actual merit, but I don't think there's any evidence one way or another.
- christophilus 5y ago
  Mercurial had its own GitHub, though. Was it bitbucket? I don’t remember, but it had an equivalent, I think. I really think Linux and performance was a key factor. Edit: I preferred hg, too, for the record.
  - throwaway894345 5y ago
    BitBucket eventually came to support Mercurial (in addition to Git and maybe others) but it was quite a long time after GitHub had been on the scene.
    - code_biologist 5y ago
      You misremember: The version control software market has evolved a lot since Bitbucket began in 2008. When we launched, centralized version control was the norm and we only supported Mercurial repos. https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket https://bitbucket.org/blog/sunsetting-mercurial-support-in-b... Github was launched in April 2008 [1]. Bitbucket is harder to find, but was definitely around by June 2008 [2]. Mercurial vs git was definitely the defining difference between the two initially, though the Rails ecosystem exploding onto Github made a huge adoption difference. git being faster + built in support for rebasing was big was well. [1] https://web.archive.org/web/20160409191635/http://www.startlin.es/timelines/github/ https://web.archive.org/web/20160409191635/http://www.startl... [2] https://web.archive.org/web/20110317200833/http://code.djangoproject.com/wiki/DjangoSuccessStoryBitbucket https://web.archive.org/web/20110317200833/http://code.djang...

seanw444 5y ago

Sourcehut (https://sr.ht https://sr.ht) seems to have support for Hg projects, though I've never tried it.

throwaway894345 5y ago
Probably, but the git vs hg debate was definitely settled by the time sr.ht hit the scene.