Hacker News Reader

Comment by sebmellen | Hacker News Reader

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.

View on HN

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

GitHub is the reason. Turns out giving beer to developers globally is an effective way to get a technology adopted.

Bitbucket used to provide free (and pretty good) Mercurial hosting.

Bitbucket had a much crappier UI.

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.

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.

Also, remember to compare the sites ten years ago rather than today.

The Torvalds effect.

I know you imply, but this could also be interpreted as "battle proven" or how about "guaranteed to still work in 30 years"

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.

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.

> I don’t even know how to pronounce “mercurial”

But you do know how to pronounce "Unnecessarily"?

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=Ide...

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.

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.

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).

Git and Linux go hand-in-hand, so there is your killer use case right there.

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

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.

It is versioned. There is git —-version. If your scripts break with the new version, don’t upgrade.

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.

This is easily fixable with a new command or envvar.

This happens all the time

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.

Just call the consistent one "ggit" and the inconsistent one "git."

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.

Reply on news.ycombinator.com