6 ms·

For some reason people love to defend the obscure and strange and oftentimes objectively terrible Git CLI. I’ve found Mercurial much more straightforward for my

For some reason people love to defend the obscure and strange and oftentimes objectively terrible Git CLI. I’ve found Mercurial much more straightforward for my (mundane and boring but prevalent) use cases, and I lament that it isn’t more widely used.

zibzab 5y ago
Every single time we are discussing git this comment shows up. But why is one popular when the other one is so much better? I guess we will never know
- disgruntledphd2 5y ago
  GitHub is the reason. Turns out giving beer to developers globally is an effective way to get a technology adopted.
  - zabzonk 5y ago
    Bitbucket used to provide free (and pretty good) Mercurial hosting.
    - oblio 5y ago
      Bitbucket had a much crappier UI.
      - zabzonk 5y ago
        Actually, one of the reasons I preferred hg to git is that Windows explorer GUI integration back then was far superior to gits, which was buggy as hell.
        ivanbakel 5y ago
        This doesn't seem relevant to the comment you're replying to. Bitbucket's web UI sucks, which is why it didn't have the effect on Mercurial that Github had on git. Having used Bitbucket and GitHub, I think GH is much nicer - both in the sense of basic stuff like page loads being faster, and in terms of features. And since it's the main tool that everyone on the development team spends their time on for communication & collaboration, those things really matter.
        mixmastamyk 5y ago
        Also, remember to compare the sites ten years ago rather than today.
- zabzonk 5y ago
  The Torvalds effect.
  - zibzab 5y ago
    I know you imply, but this could also be interpreted as "battle proven" or how about "guaranteed to still work in 30 years"
- _ph_ 5y ago
  There are several reasons. In the beginning, hg was critisized to be slow as it was written completely in python. The effect of the Linux team going with Git instead created a lot of attention to git, probably also a lot in people who were faszinated by the capabilities of git and did not care much about user friendlyness. The biggest push for git undoubtedly came from github. That is now the premier platform for hosting software, especially open source software.
- ryandrake 5y ago
  Although it sounds like a silly reason, compare the names themselves. I don’t even know how to pronounce “mercurial” without looking it up. The word doesn’t exactly roll off the tongue like git does. And then the command itself is “hg”. WTF is up with that? I mean, ha-ha we all get the joke, but was the program made for chemists? Unnecessarily clever. Don’t underestimate the extent to which a difficult/confusing name/brand can harm adoption.
  - zabzonk 5y ago
    > I don’t even know how to pronounce “mercurial” But you do know how to pronounce "Unnecessarily"?
  - j605 5y ago
    I think for most people, they would encounter it in a science class early in life (at least for English speakers). And Hg is just the chemical symbol for mercury, https://pubchem.ncbi.nlm.nih.gov/element/Mercury#section=Identifiers https://pubchem.ncbi.nlm.nih.gov/element/Mercury#section=Ide...
  - Al-Khwarizmi 5y ago
    For non-native speakers it's much more obvious how to pronounce mercurial than git. Mercurial can only be pronounced like mercury, I guess, is there any other sensible choice? But in git, it's not obvious if the g is pronounced as in get or as in gin until you look it up.
- lanstin 5y ago
  This also shows that quality of the technology matters. Like the discussion on the business value of Amazon's "use APIs always," using git is using a superior source code technology, designed from the ground up for distributed development by a master of distributed development; good things are enabled automatically. Linus' naming and UX choices and inconsistencies aside, the tool is awesome. That's why it wins in distributed development environments - the bazaar not the cathedral and not the bespoke engineering team hidden away in the corporation.
- marcosdumay 5y ago
  That is solely because of network effects. Anyone of them could be the popular one, as could any of the weirder ones like darcs, even it having technical flaws (mostly fixed by now).
- pjmlp 5y ago
  Git and Linux go hand-in-hand, so there is your killer use case right there.
grogenaut 5y ago
Personally I think it just needs a 3.0 where they completely rename all the commands so that they're really unified. I know there was pushback on this in the past
- seoaeu 5y ago
  The thing with command line interfaces is that since the same interface is used by humans and computer scripts, you essentially end up with an unversioned API that you can never make breaking changes to.
  - symlinkk 5y ago
    It is versioned. There is git —-version. If your scripts break with the new version, don’t upgrade.
    - seoaeu 5y ago
      With other sorts of APIs you are given the choice between say the v1 version or the v2 version, with both endpoints being available at the same time. However, when it comes to command line programs for all practical purposes you can only have a single version installed at a time. And it of course doesn't help that essentially none of the existing scripts even check the versions of the software they run.
      - grogenaut 5y ago
        This is easily fixable with a new command or envvar. This happens all the time
- matheusmoreira 5y ago
  That would be nice but will probably never happen due to backwards compatibility. Breaking changes in git would be even worse than the slow switch to Python 3.
  - 5y ago
cerved 5y ago
The UX philosophy is radically different. One presupposes that you understand a lot more of the underlying system. The other tries to focus on what it is what you want to do, as opposed to how. Mercurial is less intimidating if you don't know much about internals. But tbh, when I use Mercurial I still find myself searching which command to do things. As a frequent power user, I find the Git CLI to be more useable.

zibzab 5y ago

Every single time we are discussing git this comment shows up. But why is one popular when the other one is so much better? I guess we will never know

disgruntledphd2 5y ago
GitHub is the reason. Turns out giving beer to developers globally is an effective way to get a technology adopted.
- zabzonk 5y ago
  Bitbucket used to provide free (and pretty good) Mercurial hosting.
  - oblio 5y ago
    Bitbucket had a much crappier UI.
    - zabzonk 5y ago
      Actually, one of the reasons I preferred hg to git is that Windows explorer GUI integration back then was far superior to gits, which was buggy as hell.
      - ivanbakel 5y ago
        This doesn't seem relevant to the comment you're replying to. Bitbucket's web UI sucks, which is why it didn't have the effect on Mercurial that Github had on git. Having used Bitbucket and GitHub, I think GH is much nicer - both in the sense of basic stuff like page loads being faster, and in terms of features. And since it's the main tool that everyone on the development team spends their time on for communication & collaboration, those things really matter.
        mixmastamyk 5y ago
        Also, remember to compare the sites ten years ago rather than today.
zabzonk 5y ago
The Torvalds effect.
- zibzab 5y ago
  I know you imply, but this could also be interpreted as "battle proven" or how about "guaranteed to still work in 30 years"
_ph_ 5y ago
There are several reasons. In the beginning, hg was critisized to be slow as it was written completely in python. The effect of the Linux team going with Git instead created a lot of attention to git, probably also a lot in people who were faszinated by the capabilities of git and did not care much about user friendlyness. The biggest push for git undoubtedly came from github. That is now the premier platform for hosting software, especially open source software.
ryandrake 5y ago
Although it sounds like a silly reason, compare the names themselves. I don’t even know how to pronounce “mercurial” without looking it up. The word doesn’t exactly roll off the tongue like git does. And then the command itself is “hg”. WTF is up with that? I mean, ha-ha we all get the joke, but was the program made for chemists? Unnecessarily clever. Don’t underestimate the extent to which a difficult/confusing name/brand can harm adoption.
- zabzonk 5y ago
  > I don’t even know how to pronounce “mercurial” But you do know how to pronounce "Unnecessarily"?
- j605 5y ago
  I think for most people, they would encounter it in a science class early in life (at least for English speakers). And Hg is just the chemical symbol for mercury, https://pubchem.ncbi.nlm.nih.gov/element/Mercury#section=Identifiers https://pubchem.ncbi.nlm.nih.gov/element/Mercury#section=Ide...
- Al-Khwarizmi 5y ago
  For non-native speakers it's much more obvious how to pronounce mercurial than git. Mercurial can only be pronounced like mercury, I guess, is there any other sensible choice? But in git, it's not obvious if the g is pronounced as in get or as in gin until you look it up.
lanstin 5y ago
This also shows that quality of the technology matters. Like the discussion on the business value of Amazon's "use APIs always," using git is using a superior source code technology, designed from the ground up for distributed development by a master of distributed development; good things are enabled automatically. Linus' naming and UX choices and inconsistencies aside, the tool is awesome. That's why it wins in distributed development environments - the bazaar not the cathedral and not the bespoke engineering team hidden away in the corporation.
marcosdumay 5y ago
That is solely because of network effects. Anyone of them could be the popular one, as could any of the weirder ones like darcs, even it having technical flaws (mostly fixed by now).
pjmlp 5y ago
Git and Linux go hand-in-hand, so there is your killer use case right there.

grogenaut 5y ago

Personally I think it just needs a 3.0 where they completely rename all the commands so that they're really unified. I know there was pushback on this in the past

seoaeu 5y ago
The thing with command line interfaces is that since the same interface is used by humans and computer scripts, you essentially end up with an unversioned API that you can never make breaking changes to.
- symlinkk 5y ago
  It is versioned. There is git —-version. If your scripts break with the new version, don’t upgrade.
  - seoaeu 5y ago
    With other sorts of APIs you are given the choice between say the v1 version or the v2 version, with both endpoints being available at the same time. However, when it comes to command line programs for all practical purposes you can only have a single version installed at a time. And it of course doesn't help that essentially none of the existing scripts even check the versions of the software they run.
    - grogenaut 5y ago
      This is easily fixable with a new command or envvar. This happens all the time
matheusmoreira 5y ago
That would be nice but will probably never happen due to backwards compatibility. Breaking changes in git would be even worse than the slow switch to Python 3.
- 5y ago

cerved 5y ago

The UX philosophy is radically different. One presupposes that you understand a lot more of the underlying system. The other tries to focus on what it is what you want to do, as opposed to how. Mercurial is less intimidating if you don't know much about internals. But tbh, when I use Mercurial I still find myself searching which command to do things. As a frequent power user, I find the Git CLI to be more useable.