Hacker News Reader

Comment by midenginedcoupe | Hacker News Reader

Absolutely.

I've seen teams evaluate multiple revision systems before starting projects and each one has decided on Mercurial based on its technical merits.

I'll take it on trust that git is a perfect solution for linux kernel development, but the number of teams who work the same way as them is a rounding error from zero. I see people on here complaining about cargo-culting from the cool kids (k8s, spotify's team structures, etc., ect.), but I see git as exactly the same.

I don't want to have to spend time understanding how my editor handles lines in memory in order to use it, why should I have to spend time understanding how my revision control system treats revisions?

Tech is hard enough without having to sink time in to unnecessarily complicated tools that can bite you in the bum really hard.

View on HN

Mercurial is really nice. I find its CLI interface much less confusing than Git's. I think a lot of this has to do with Git's "index" where you have to "add" files and then "commit" them. This seems like the #1 source of confusion when people are learning Git and persists into operations like "rebase" and "cherry-pick" where the index is used for marking conflicts as resolved or not.

I personally always liked the flexibility the stage offers.

Oh, I agree. It definitely has advantages once you get the hang of it! It might be nice if it was optional though so newbies could ignore it entirely.

> I see people on here complaining about cargo-culting from the cool kids (k8s, spotify's team structures, etc., ect.), but I see git as exactly the same.

I think this explains a lot of the initial popularity of git and github. Wanting to be like the cool kids, and git knowledge being seen as somehow "elite" back then.

But given that initial popularity, it seems likely to me that network effects mostly explain its growth in usage from there. Convergence on a single revision control tool/site/representation/api/etc is probably inevitable, in the same way that there is basically a single social network (ie Facebook).

> I see people on here complaining about cargo-culting from the cool kids (k8s, spotify's team structures, etc., ect.), but I see git as exactly the same.

The big advantage of git is github and co, not git itself. By switching and using mercurial you lose all of the advantages of github too.

Well that's a different argument.

The irony is I use git for all my projects, too, due to the network effect. It's vastly easier to go with the flow rather than swim against the tide. But every time I have to wrestle with un-fucking git's state I find myself considering my life choices and how I got there :(

> But every time I have to wrestle with un-fucking git's state I find myself considering my life choices and how I got there :(

cough Fossil cough

Amen to that. I love Fossil for its simplicity and batteries included model. No external ticketing, wiki and documentation to manually keep in sync. Plus everything inside a single SQLite file makes everything easier.

I thought that mercurial was able to push/pull from a git remote.

You can use the hg-git extension for that:

https://hg-git.github.io/

Or there's sourcehut so you can use Hg. https://sr.ht

It's not as “accessible” though: it's not free and is less user-friendly.

During the alpha, SourceHut is free to use, except for builds.sr.ht, which was abused by crypto script kiddies.

I think you can pay as low as 2 dollars a month to use SourceHut.

> git is a perfect solution for linux kernel development, but the number of teams who work the same way as them is a rounding error from zero.

Yeah, but saying that here a few years ago got you lynched.

Reply on news.ycombinator.com