← Back to context

Comment by awesome_dude

15 hours ago

Whatever your opinion on one tool or another might be - it does seem weird that the "market" has been captured by what you are saying is a lesser product.

IOW, what do you know that nobody else does?

So far you've only gotten responses to "how can a worse product win?", and they are valid, but honestly the problem here is that Mercurial is not a better product in at least one very important way: branches.

You can visit any resource about git and branches will have a prominent role. Git is very good at branches. Mercurial fans will counter by explaining one of the several different branching options it has available and how it is better than the one git has. They may very well be right. It also doesn't matter, because the fact that there's a discussion about what branching method to use really just means Mercurial doesn't solve branches. For close to 20 years the Mercurial website contained a guide that explained only how to have "branches" by having multiple copies of the repository on your system. It looks like the website has now been updated: it doesn't have any explanation about branches at all that I can find. Instead it links to several different external resources that don't focus on branches either. One of them mentions "topic", introduced in 2015. Maybe that's the answer to Git's branching model. I don't care enough to look into it. By 2015 Git had long since won.

Mercurial is a cool toolbox of stuff. Some of them are almost certainly better than git. It's not a better product.

  • It's interesting that branches, which is a marquee feature of git, became less important at the same time as git ate all the other vcs. Outside of OS projects, almost all development is trunk based with continuous releases.

    Maybe branching was an important reason to adopt git but now we'd probably be ok with a vcs that doesn't even support them.

    • Not sure if it's true. I mean, I do agree with the core of it, but how do you even do PRs and resolve conflicts, if there are no branches and a developer cannot efficiently update his code against the last (remote) version of master branch?

  • This is so strange, because, at a low level, a branch isn't even a "thing" in git. There is no branch object type in git, it's literally just a pointer to a commit, functionally no different from a tag except for the commands that interact with it.

    • Meanwhile mercurial has bookmarks. TBF I'm not sure when it got those but they've been around forever at this point. The purpose is served.

      I think there are (or perhaps were) some product issues regarding the specifics of various workflows. But at least some of that is simply the inertia of entrenched workflows and where there are actual downsides the (IMO substantial) advantages need to be properly weighed against them.

      Personally I think it just comes down to the status quo. Git is popular because it's popular, not because it's noticably superior.

    • That's the definition of a tree though. Everything has a parent, no cycles allowed.

GitHub had a business model where public repos were free. BitBucket didn’t.

That’s it. That’s why git won, you could put up open source libs with one for free and not the other.

Which is extra funny as the centralized service was the most important part of decentralized version control.

Worse products win all the time. Inertia is almost impossible to overcome. VHS vs Betamax is a classic. iPod wasn’t the best mp3 player but being a better mp3 player wasn’t enough to claw market share.

Google and Meta don’t use Git and GitHub. Sapling and Phabricator much much better (when supported by a massive internal team)

Network effects and marketing can easily prevent better tools from winning.

  • I mean, in the fickle world that is TECH, I am struggling to believe that that's what's happened.

    I personally went from .latest.latest.latest.use.this (naming versions as latest) to tortoise SVN (which I struggled with) to Git (which I also was one of those "walk around with a few memorised commands" people that don't actually know how to use it) to reading the fine manual (well 2.5 chapters of it) to being an evangalist.

    I've tried Mercurial, and, frankly, it was just as black magic as Git was to me.

    That's network effects.

    But my counter is - I've not found Mercurial to be any better, not at all.

    I have made multiple attempts to use it, but it's just not doing what I want.

    And that's why I'm asking, is it any better, or not.

    • Networking effects are significantly strengthened by necessary user buy in. VC is hard, and every tool demands its users to spend a non-significant amount of time learning it. I would guess the time to move from black magic to understanding most of git is ~100h for most people.

      The thing is, to understand which one is actually better, you would have to give the same amount of investment in the second tool, which is not something most people are willing to do if the first tool is "good enough". That's how Python became the default programming language; people don't miss features they do not understand.

      2 replies →

    • Mercurial has a more consistent CLI, a really good default GUI (TortoiseHg), and the ability to remember what branch a commit was made on. It's a much easier tool to teach to new developers.

      1 reply →

That worse is better, and some people don't know better or care.

  • "better" in that sentence is very specific. Worse is also worse, and if you're one of the people for whom the "better" side of a solution doesn't apply, you're left with a mess that people celebrate.

Welcome to VHS and Betamax. the superior product does not always win the market.

  • Not always, but in this case the superior product (i.e. VHS) won. At initial release, Beta could only record an hour of content, while VHS could record 2 hours. Huge difference in functionality. The quality difference was there, but pretty modest.