Live data from Hacker News

I kind of killed Mercurial at Mozilla

glandium.org

151–160 of 250 posts

Re: I kind of killed Mercurial at Mozilla

#151
post #77
post #5

Earlier quoted context omitted.

FB/Meta replaced Mercurial with Sapling which is git-compatible: https://engineering.fb.com/2022/11/15/open-source/sapling-so... Mercurial is over.

And Google has been putting much of their investment behind jj. One other interesting thing I've noticed, mercurial has stopped building windows standalone releases. It's been that way for around 9 months.

What’s jj?

Re: I kind of killed Mercurial at Mozilla

#152

Earlier quoted context omitted.

Git functionality is great. But the CLI just kind of grew in a nonsensical way. No serious effort seems to have been made on UX consistency and verb/noun names. People who've been using it for years don't notice, they don't even think about it. But when coming from scratch, it's anything but intuitive. The CLI is not discoverable in a reasonable way. That and there's so many ways to use it. Mercurial had the advantag…

Exactly this. To be perfectly honest, the git CLI is so bad that I would take pretty much anything over git. I would prefer SVN over git, despite that product being older and with less functionality, just because it's at least easy to use. I learned and use git because that's just how the industry has moved, and I'm pragmatic enough to just roll with it. But good Lord, the UI is a case study in "programmers shouldn't…

> I would prefer SVN over git

Yes SVN has so much better CLI especially for things like

  * merging

  * history navigation

  * searching commit messages, filenames and file content

  * bisecting
I'm filled with joy remembering good old SVN days and how my life was a way easier.

Re: I kind of killed Mercurial at Mozilla

#153
post #130

Earlier quoted context omitted.

The day-to-day workflow at Meta is still using the hg frontend and regular hg commands. I would love to see the git frontend used instead, but, it hasn't happened yet.

I've switched over to using `sl` commands. Sapling is installed on ODs by default. Main change I had to get used to was `up(date)` became `goto`.

I assume this is a different sl than https://man.cx/sl(6)

Re: I kind of killed Mercurial at Mozilla

#154
post #117

Earlier quoted context omitted.

> It's just the network effect It's almost like qwerty vs dvorak in that regard, except git and mercurial were contemporaries. Mercurial isn't quite good enough to displace git, and git has Linus as a promoter which was all it needed to be the leader. That said, I agree that the network effect of having just one is more valuable than mercurial's ergonomics (which could still use a good branch story).

Mercurial also missed the window on performance and safety. If you started using it around 2009 or so, Hg was notably slower for daily use and a lot of people recommended using extensions to match Git features but those extensions were not stable (Hg and RCS are the only VCSes I’ve seen require data to be recovered from a backup due to normal usage). There’s a meme that Git is hard to use but I think it’s conflating…

> Hg was notably slower for daily use

There was an interview with Linus Torvalds at some point where he points out that Mercurial was one of the tools he tried using to replace Bitkeeper, but found it to be much to slow. Has he tells it in the interview he later learned that the slowness he experienced was due to a bug in Mercurial and had that not been there, git might never have happened.

If that's true it a little sad, but I also wonder if many of us might still be on SVN, Perforce or whatever. Git, by being a product of Linus brought a lot of focus on Git. Bitkeeper never got the same attention, that was a commercial product, but being used for kernel development didn't see to promote it as much as I'd expect.

Re: I kind of killed Mercurial at Mozilla

#155

Earlier quoted context omitted.

Yes it’s also been rewritten since acquisition which was when hg support was dropped afaik

Why was it rewritten?

If i recall correctly the server/enterprise version was completely separate product written in java (as opposed to python which powered original bitbucket.com). I think the java eventually subsumed the cloud product but not too sure of that

Re: I kind of killed Mercurial at Mozilla

#156
post #153

Earlier quoted context omitted.

I've switched over to using `sl` commands. Sapling is installed on ODs by default. Main change I had to get used to was `up(date)` became `goto`.

I assume this is a different sl than https://man.cx/sl(6)

While the real sl (Steam Locomotive) isn't installed on that many systems, I can only imagine the annoyance that it must bring to any former Facebook engineers when they assume that it's the version control

Re: I kind of killed Mercurial at Mozilla

#157
post #81

Earlier quoted context omitted.

I want to say bitbucket started out as this, at least my first repos there were hg.

yep, that's what i used to use, but it was shut down and i don't really know why - would it have cost so much to have kept it open? dunno - i really know nothing about the economics of keeping such things going.

I don't recall if this was before or after Atlassian bought Bitbucket, but they had a number of issues keeping the site running. There where so many outages, the site was frequently slow to the point of being useless. I know because we where a paying customer. I suspect that they had to few paying customers and because the service was so prone to outages they had acquired a bad reputation so they couldn't attract new customers. Maybe if Bitbucket had been a Silicon Valley company they would have had access to funding, allowing them to grow in the same way Github did.

When it worked it was fine, but in the end you just got way better service and performance on Github.

The current iteration of Bitbucket isn't even Bitbucket, it's Stash. That works really well to, if you like Atlassian tools.

Re: I kind of killed Mercurial at Mozilla

#158
post #108

I don't understand why so many people seem to dislike git. But maybe in actuality it is not many people, as usually people who are discontent are the loudest. I used Mercurial in the past for a bit, and it was fine. But for me it doesn't seem to have any huge advantages over git, if any. And after so many years of experience using git, I know what workflows work well, how to resolve merge conflicts, how to revert to…

Aside from the terrible UI that several other people have mentioned, there are some other things that Git does badly (though I don't know if Mercurial does better): * Large projects. It has poor monorepo support (especially on Linux), and also poor multirepos support (submodules are really buggy). * Large files. LFS is a PoC-level hack; not a proper solution. * Conflict resolution. The default diff algorithm is very…

Git is very good with large repos, but the monorepo concept doesn't fit the git model. Monorepo is a bad idea with the current DVCS-es unless you use custom tooling. My guess is that people adopt monorepos because they aspire to be Google-scale, but it usually doesn't make sense for their workflow.

If you want monorepo, use Perforce or SVN, but good luck with the speed ;)

Re: I kind of killed Mercurial at Mozilla

#159
post #153

Earlier quoted context omitted.

I assume this is a different sl than https://man.cx/sl(6)

While the real sl (Steam Locomotive) isn't installed on that many systems, I can only imagine the annoyance that it must bring to any former Facebook engineers when they assume that it's the version control

I wonder how many typoed invocations of ls correspond to sl commands. Like if you have an update directory.

Although now that I think about it, if hg had displayed a steam locomotive, maybe people wouldn't have noticed how slow it was...

Re: I kind of killed Mercurial at Mozilla

#160
post #78

Earlier quoted context omitted.

> Originally, separate clones was the recommended way to do "topic branches" in Mercurial This is still what the Guide on the Mercurial site mentions as the "basic workflow" for working on separate features. Named branches are considered "advanced", and bookmarks are an afterthought entirely. About 10 years ago, after reading a lot about how hg was more intuitive than git, I decided to give it a try. I was already us…

> This is still what the Guide on the Mercurial site mentions as the "basic workflow" ... I imagine you're referring to the "hg book"[1] ? It irks me that that site hasn't been updated since ~2009, and there doesn't seem to be anything equivalent for "modern" Mercurial. Alas. EDIT: oh, looks like there is a somewhat newer version (~2015?): https://book.mercurial-scm.org/read/part-getting-started.htm... [1] http://hgb…

> I imagine you're referring to the "hg book"[1] ?

No, I mean when you go to the site and click the second item in the menu, Guide[1].

[1]: https://mercurial-scm.org/guide

Post reply on HN