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.
I kind of killed Mercurial at Mozilla
151–160 of 250 posts
Re: I kind of killed Mercurial at Mozilla
#152Earlier 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…
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
#153Earlier 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`.
Re: I kind of killed Mercurial at Mozilla
#154Earlier 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…
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
#155Earlier quoted context omitted.
Yes it’s also been rewritten since acquisition which was when hg support was dropped afaik
Why was it rewritten?
Re: I kind of killed Mercurial at Mozilla
#156Earlier 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)
Re: I kind of killed Mercurial at Mozilla
#157Earlier 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.
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
#158I 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…
If you want monorepo, use Perforce or SVN, but good luck with the speed ;)
Re: I kind of killed Mercurial at Mozilla
#159Earlier 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
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
#160Earlier 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…
No, I mean when you go to the site and click the second item in the menu, Guide[1].