Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I kind of killed Mercurial at Mozilla

glandium.org

Post reply on HN
Print view View original

171–180 of 250 posts

Re: I kind of killed Mercurial at Mozilla

#171

Post by muxator »

crdrost wrote: post #90
interroboink wrote: post #41

I liked the thorough article, but my goodness did they beat around the bush w/regard to their actual contribution to this process (per the title). I think the short version is: they made `git-cinnabar`, which is a git-to-hg translator, to help git users interact with the Mozilla repos. ---- One contribution I can make: > For reasons I don't know, Mozilla decided to use separate Mercurial repositories as "branches". O…

> Aside: I prefer Mercurial myself, and I hope to keep using it for personal projects until I die (: One of my favorite stories happened three or four jobs ago... at this job I kept a giant whiteboard that I had swiped from a conf room, behind my cubicle. And whenever anybody asked questions we put it up on the board. We were an SVN shop and someone had asked how Git worked and I was like "do you want me to explain G…

> Aside: I prefer Mercurial myself, and I hope to keep using it for personal projects until I die (: ... > you could! let me show you TortoiseHg...

Same here. I use TortoiseHg daily and propose the occasional contribution when something breaks/can be improved. It is really a project that has been chugging away for more than 15 years now.

Re: I kind of killed Mercurial at Mozilla

#172

Post by glandium »

kbrosnan wrote: post #169
glandium wrote: post #53

Earlier quoted context omitted.

Author here. > my goodness did they beat around the bush w/regard to their actual contribution to this process (per the title). Fair point. I came up with the title first. Then as the content grew large and diluted the essence of the title, I reconsidered, but ended up sticking to it as a shameless clickbait. > Originally, separate clones was the recommended way to do "topic branches" in Mercurial (not to be confused…

Tracking down preed, JST, joduin, bsmedberg, etc might turn up stories. Some of it is captured by preed in https://soberbuildengineer.com/blog/2006/11/version-control-... and announcing hg in https://soberbuildengineer.com/blog/2007/04/version-control-... JST post on bzr vs hg perf, https://web.archive.org/web/20070219012211/http://weblogs.mo...

If you look closely, I linked to preed's posts. :) (look for "colorful")

Jst's post is linked from the second one. (but is a dead link)

Re: I kind of killed Mercurial at Mozilla

#173

Post by culebron21 »

wsc981 wrote: 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…

Despite having 14 years of experience with Git, I still can't use it without Stackoverflow for any non-daily task. And I've read the internals back in 2008 and understand this, but it doesn't make it any clear how merges, conflict resolution, or amendments to commits work. Absolutely confusing. In Mecrurial a lot more stuff is clear and easy to remember.

Example: I tried rebasing or merging, and got merge conflicts. Started resolving them, git-added some of files, but got stuck, and want to get back to the last commit. git-reset doesn't work. How do I get there? No idea. How does the knowledge of commit hashes, branches and staging area help me? It doesn't.

Re: I kind of killed Mercurial at Mozilla

#174

Post by guenthert »

acdha wrote: post #117
dehrmann wrote: post #98

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…

> There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all

Not sure about that. Git certainly doesn't make it easier by idiosyncratic use of terms and behavior. Why does 'pull' imply 'checkout'?

Re: I kind of killed Mercurial at Mozilla

#175

Post by HelloNurse »

mrweasel wrote: post #154
acdha wrote: post #117

Earlier quoted context omitted.

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…

Bitkeeper was more or less like Subversion, fast, expensive and slightly complicated; you seem to overestimate the relevance and influence of Linux kernel use for the average corporate decision maker who doesn't care about Linux, doesn't care about distributed VC, doesn't care about performance (because it only affects peons), doesn't like to spend money and doesn't like bleeding edge tools.

Re: I kind of killed Mercurial at Mozilla

#176

Post by muxator »

kyrra wrote: post #77
wmf wrote: 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.

I think Matt Harbison takes care of Windows builds. They are bundled with the official TortoiseHg download:

https://tortoisehg.bitbucket.io/download/

I did not use them because I am on linux only, but I see that Matt is active and responsive, both on the mailing list and chasing bugs on the issue tracker on heptapod ( https://foss.heptapod.net/mercurial/tortoisehg/thg )

Re: I kind of killed Mercurial at Mozilla

#177

Post by jillesvangurp »

BrenBarn wrote: post #140

I hate to see more and more people switching from Mercurial to Git. The way to overcome the "network effects" is exactly for large projects like Mozilla to stand tall and say clearly that they are going to use Mercurial because it is better and git is worse . Of course, I shouldn't really expect such from Mozilla given all the other dubious actions they've taken over time.

You'd need some arguments for the assertion that mercurial is better. I think Mozilla is switching because of years of failing to come up with good arguments. And it looks like they gave it a lot of thought. That and an increasing dependence on git internally to the point where people were spending non trivial amounts of time engineering around mercurial and coming up with all sorts of hacks to enable git usage. At least, that's what the article suggests actually happened.

You'll never get consensus on X being better than Y in the tech world. There are always going to be people that insist Y is better than X. And more power to them. But you have to be realistic. There is a lot of stuff that just never gets a lot of traction. Mercurial is one of those things. It's like betamax vs. vhs.

Initially it looked promising and then Github happened and the rest is history. The whole industry now runs on Git and Mercurial sort of flat lined in terms of growth after Github started hosting essentially the entirety of the OSS world (with few but notable exceptions of course). At this point it's a hard sell for new projects and some of the larger remaining users are switching away or are considering it.

Re: I kind of killed Mercurial at Mozilla

#178

Post by otabdeveloper4 »

billllll wrote: post #20
galkk wrote: post #2

Interesting, given that Google and Facebook [2], at least, eventually moved to have their repositories offered via Mercurial interface, instead of git. I also would expect that Github eventually will also offer mercurial repos. p.s. And let's not talk about abomination that is GitLFS (starting from the fact that it requires separate subcommand). [2] https://engineering.fb.com/2014/01/07/core-infra/scaling-mer...

Bitbucket dropped Mercurial support in 2020: https://bitbucket.org/blog/sunsetting-mercurial-support-in-b... I just don't think there is good RoI for implementing Mercurial support. It really isn't about the interface (which I think most people agree hg is better than git). It's just the network effect: most projects use git so everybody learns git and they don't want to learn another tool even if it's better in some…

> It's just the network effect

No, it isn't. Git is unopinionated and doesn't try to shove some half-baked idea of "best practices" and "you're doing it wrong" down your throat.

This means there is no friction in adopting Git at the workplace.

Re: I kind of killed Mercurial at Mozilla

#179

Post by pravus »

acdha wrote: post #117
dehrmann wrote: post #98

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…

> There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all

No. I had used CVS, SVN, SVK, Bazaar, and Mercurial for years before I switched to Git. I can generally explain the internals of all of these tools (a DAG) to someone in simple terms in minutes. Overlaying that onto the commands becomes easy.

What Git does is take that concept and wrap it in the worst possible workflow UI. The people that immediately grafted onto the Git community cheered this on for some reason very early and then recanted by saying that you are really supposed to build "porcelain" for Git since it was meant to be a rough tool.

To this day all I see are articles about people's confusions and conniptions over simple things that Git does incorrectly because it's UI is horrible. Most can't even get to the point where they understand the DAG. Even though I know what is supposed to happen it's hard for me to fumble around with simple commands because the naming is inconsistent and I have to research to find solutions. This was rarely an issue with Mercurial and when I talk to people that have used both they seem to share that sentiment.

Git is the PHP of version control. Widely used and very popular but has a lot of architectural problems that make it a total mess.

Re: I kind of killed Mercurial at Mozilla

#180

Post by jgraham »

pcwalton wrote: post #119
interroboink wrote: post #41

I liked the thorough article, but my goodness did they beat around the bush w/regard to their actual contribution to this process (per the title). I think the short version is: they made `git-cinnabar`, which is a git-to-hg translator, to help git users interact with the Mozilla repos. ---- One contribution I can make: > For reasons I don't know, Mozilla decided to use separate Mercurial repositories as "branches". O…

One of the biggest problems with Mercurial is that they took a long time for histedit to become a usable workflow. I speculate (without any evidence, so this could be entirely wrong) that this is because many Mercurial contributors preferred MQ over editing history for local patches. (Certainly I knew many Gecko developers who swore by MQ.) Coming from Git, with the git rebase --interactive flow coupled with the refl…

Yes, I think it's under-appreciated how much git and mercurial were ideologically different in their attitudes to history rewriting.

The generally accepted narrative these days is that git became popular because of github (with the implicit assumption that was an arbitrary choice) and/or the Linux kernel (without much questioning of why people specifically cared about Linux's tooling for wource control).

But what I remember from ~2010 was a load of blog posts eulogizing history rewriting and how it allowed you to separate out the activities of committing changes locally in order to record the state of your work at various times, and assembling the final patch into something suitable for review by others.

Meanwhile mercurial took the stance that history rewriting is bad, and as a result people ended up using even worse solutions like `mq`, which is basically tooling around directories full of numbered patch files.

You still see that distinction in hg: once it eventually did realise that history editing is a desirable feature for many reasonable workflows it added a lot of additional complexity to the basic model, with features like phases (supposed to stop you rewriting commits that someone else might be depending on, but just using the proxy measure of "was this pushed to a 'publishing' repo") and "evolve" (which keeps a complete history of history rewrites; useful in principle for tools like code review systems to avoid the common pattern of putting a "patch id" into the commit message, but in practice felt like a lot of extra mental overhead).

So at least my view is that git made a "practicality beats purity" bet on history rewriting being a net good, and hg made the opposite bet, and eventually lost.

And back on the original topic, I used hg personally before I used git, and then professionally at Mozilla before git cinnabar came along (although by this point I was using git in other projects). So I've used mercurial a lot but actively prefer git when given a choice. Nevertheless I think this article understates just how good cinnabar is compared to the options that preceded it; apart from the case where you have a hg hash from an external system and want to find the commit locally (where you just run `git cinnabar hg2git`) it's basically totally seamless and just works without problems. It's a small tool that does one thing really well, to the extent that it's easy to overlook just how good it really is.

Post reply on HN