logoalt Hacker News

PathOfEclipsetoday at 7:17 PM14 repliesview on HN

Almost 20 years ago I helped our company choose between Git and Mercurial as the replacement for Subversion. Unfortunately, I helped them make the wrong choice, Mercurial.

I say wrong because clearly Git won the war and I haven't used Mercurial since then. However, I still think I made the right choice from a technical perspective; I thought Mercurial was way more user-friendly while providing all the features and performance needed. But I guess I couldn't read the future in terms of which one would win out!


Replies

sampotoday at 9:43 PM

> But I guess I couldn't read the future in terms of which one would win out!

After Linus Torvalds gave this talk at Google in 2007, it was clear he would win. (Is there a better quality video somewhere?)

https://www.youtube.com/watch?v=idLyobOhtO4

But I agree: Mercurial was definitely friendlier for people who didn't have time time to go through the technicalities of git. To use git smoothly you pretty much need to learn how it works internally.

jjavtoday at 8:28 PM

Mercurial is one of the many sad stories of far better technology being forgotten by the popularity contest juggernaut of something else.

I still use mercurial for all my personal project where I don't need to care what anyone else thinks. It is pleasant to use good tools, just like I like to buy top quality rachets or such.

show 3 replies
3formtoday at 7:59 PM

I'm glad that I stuck to git for a similar reason; it won the war. And I understand the need for simpler tools.

But to offer a point I haven't heard from anyone before: at least I feel that I am done with it, I learned this tool sufficiently and I can move on with my life. From time to time I add something to my git toolbelt. I feel if Mercurial or anything else have won, I would maybe have to learn another tool in 5 years, whatever else got popular, and another in next 5 years. But now I have everything I need in git, and always have needed. I hold some hope in it that perhaps the learning curve was worth it.

show 2 replies
yegletoday at 8:24 PM

I have the feeling that Git winning the war hinges heavily on GitHub being the way to do open source projects, and that is changing given the sad state of GitHub.

Another contender is Jujutsu (jj) which allows you to use jj as frontend and use Git as the backend (with the potential to support any backend, e.g. Google's proprietary Piper), with the best ergonomic and the widest availability of hosting solutions.

show 2 replies
avaruntoday at 7:23 PM

Around 20 years ago Facebook made the same choice, so you're in good company in terms of technically sophisticated shops.

show 1 reply
forestotoday at 8:51 PM

> I helped them make the wrong choice, Mercurial.

20 years ago, Mercurial was not the wrong choice.

- Its internal design was very similar to Git's.

- Its cross-platform support was superior to Git's. (Git didn't get good Windows support until some years later.)

- Its ergonomics were superior to Git's, which was an important factor on its own, and especially important when trying to get a whole organization to retrain and retool around a distributed model.

- (It had a third major advantage over Git that I unfortunately cannot recall at the moment.)

So you weren't wrong back then...

...but Git improved over time, tipping the scale closer to a balanced state. It also had unbeatable author recognition, making it the obvious choice for anyone unaware of Mercurial's advantages, and eventually leading it to benefit from the network effect. And GitHub appeared, greatly improving Git's ecosystem with no support for Mercurial.

show 2 replies
tempest_today at 7:41 PM

Our company also made this choice.

One of the first things I did was switch us to git.

Mercurial was way easier to use and fit our use case but all the tooling was built for git.

amlutotoday at 7:48 PM

I also did this. Both in hindsight and at the time, I thought Mercurial had far better tooling. But it was not all amazing: Mercurial’s branching model was very poor, and its sequentially numbered revision system was and remains a very bad design.

show 4 replies
woadwarrior01today at 7:19 PM

I'd made the exact same choice around the same time at the company where I was working. Last I heard, they're still using it. My rationale was that Mercurial was a lot safer and user-friendly compared to git. Needless to say, git has improved by leaps and bounds since then.

qwerytoday at 8:07 PM

I don't think Git winning a popularity contest is a reason for choosing Mercurial to have been wrong, or unfortunate. Was there some negative consequence from the decision -- either directly from Mercurial itself, or just because over time everyone expected Git, perhaps?

(Hopefully this comes across as curious, which it is, and not antagonistic, which its not)

show 1 reply
dismalaftoday at 9:18 PM

I used Mercurial back in the day too. I agree, it was better. That being said, GitHub was better than other similar services which no doubt helped git win and now, git is ubiquitous.

justsomehnguytoday at 7:57 PM

You did the right at the right time, you wasn't some prescient being. Why are you

fHrtoday at 8:31 PM

meanwhile my org still uses svn for a lot of repos at least my teams are full git...ugh

martin-ttoday at 8:43 PM

I hate that social factors like popularity are a thing in technical decisions.

I have not used mercurial (though heard good things about it) but I saw a similar thing play out in Rust gamedev. There are 2 competing game engines, one better technically, the other much more popular. Now, if everyone made a purely technical decision, they'd pick the first one and eventually it would become the more popular one. Unfortunately, whenever I asked people why they chose the second one, they said because it was more popular. Tragedy of the commons.

If it's any consolation, maybe jj will take over. I haven't tried it yet (I use the staging area a lot in my workflow), but AFAIK they made the choice to be git-compatible which means it's not a choice between one or the other but lets people and teams migrate gradually.

show 1 reply