5 ms·

While I have learned to be mostly competent when it comes to git day-to-day tasks, I still miss hg for it's clean interface design and simplified workflow.

muxator 5y ago
Hg in itself is alive and well. Interacting with git repositories works well with hg-git. But it is true that, for the mindset of the general public (or younger developers), it might well be nonexistent. It is a shame, since life with mercurial is still so easier.
taeric 5y ago
I'm curious what makes you consider it clean? I'm specifically not claiming otherwise; I just don't know what that claim means.
- Beltalowda 5y ago
  Mercurial is much more straightforward to work with for most common workflows (but can still be extended for other, less common, workflows). I found that I can use mercurial effectively just by reading the built-in help. With git ... not so much. Not that the documentation on git is bad necessarily, there's just so much of it. A simple demonstration of this might be something like: % git help commit | wc -l 622 % hg help commit | wc -l 59 % hg help commit -v | wc -l 98 And some of the CLI syntax is rather arcane, too. It's been years since I last used mercurial, so I'd have to go back to find more specific examples, but I struggled a lot more getting started with git than with mercurial.
  - taeric 5y ago
    It's odd, to me, as I remember not being able to figure out mercurial back in the day. Guessing I had just already made the mental shift to git? That said, size of manual doesn't seem compelling. The men page for ls, as an example, would make that seem a very tough command to use.
    - Beltalowda 5y ago
      Some people have said they found git more intuitive and easier; its not something objective. > That said, size of manual doesn't seem compelling. The men page for ls, as an example, would make that seem a very tough command to use. Sure; it's just indicative of complexity, and therefore, ease-of-use.
throwaway894345 5y ago
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.
yjftsjthsd-h 5y ago
Oh yeah, hg was way easier to learn, and IMO to understand. I'm very happy that I learned hg first and then picked up git; I think learning hg first was "easy mode" and then extending to git was easier to learn in turn.

muxator 5y ago

Hg in itself is alive and well. Interacting with git repositories works well with hg-git. But it is true that, for the mindset of the general public (or younger developers), it might well be nonexistent. It is a shame, since life with mercurial is still so easier.

taeric 5y ago

I'm curious what makes you consider it clean? I'm specifically not claiming otherwise; I just don't know what that claim means.

Beltalowda 5y ago
Mercurial is much more straightforward to work with for most common workflows (but can still be extended for other, less common, workflows). I found that I can use mercurial effectively just by reading the built-in help. With git ... not so much. Not that the documentation on git is bad necessarily, there's just so much of it. A simple demonstration of this might be something like: % git help commit | wc -l 622 % hg help commit | wc -l 59 % hg help commit -v | wc -l 98 And some of the CLI syntax is rather arcane, too. It's been years since I last used mercurial, so I'd have to go back to find more specific examples, but I struggled a lot more getting started with git than with mercurial.
- taeric 5y ago
  It's odd, to me, as I remember not being able to figure out mercurial back in the day. Guessing I had just already made the mental shift to git? That said, size of manual doesn't seem compelling. The men page for ls, as an example, would make that seem a very tough command to use.
  - Beltalowda 5y ago
    Some people have said they found git more intuitive and easier; its not something objective. > That said, size of manual doesn't seem compelling. The men page for ls, as an example, would make that seem a very tough command to use. Sure; it's just indicative of complexity, and therefore, ease-of-use.

throwaway894345 5y ago

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.

yjftsjthsd-h 5y ago

Oh yeah, hg was way easier to learn, and IMO to understand. I'm very happy that I learned hg first and then picked up git; I think learning hg first was "easy mode" and then extending to git was easier to learn in turn.