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

181–190 of 250 posts

Re: I kind of killed Mercurial at Mozilla

#181

Post by maccard »

glandium wrote: post #53
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…

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…

> 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.

I enjoyed it. It could maybe have been two posts, but it's a headline, it's supposed to get you to click on it.

And it's true, too.

Re: I kind of killed Mercurial at Mozilla

#182

Post by fragmede »

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…

We'll never know. But git being used to manage the Linux Kernel did a lot for its asendency. if Mercurial had been the choice, maybe we'd all be on Hghub instead of Github. Bitkeeper's proprietary status is what dampened enthusiasm there.

Re: I kind of killed Mercurial at Mozilla

#183

Post by IshKebab »

dig1 wrote: post #158
IshKebab wrote: post #149

Earlier quoted context omitted.

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 ;)

> Git is very good with large repos

Not really. It only very recently got support for partial clones, sparse checkouts (still experimental!) `git status` daemon (only on Windows and Mac!), etc. And that's only because Microsoft is pushing it.

> My guess is that people adopt monorepos because they aspire to be Google-scale, but it usually doesn't make sense for their workflow.

Rubbish, it's nothing to do with wanting to be Google-scale. In fact being Google-scale makes a monorepo more difficult and require custom tooling.

The reason people like monorepos is because they don't have the downsides of multirepos:

* Cross-repo changes are very difficult to do and even harder to test.

* Testing code becomes very difficult. For example if you update a library that's in one repo, how do you test all the things that depend on it? Very difficult with multirepos, trivial with monorepos.

* Git's support for submodules is really bad.

The downside of monorepos is that they are big and slow, but they work fine as long as you aren't Google scale.

Re: I kind of killed Mercurial at Mozilla

#184

Post by postexitus »

otabdeveloper4 wrote: post #178
billllll wrote: post #20

Earlier quoted context omitted.

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.

my git reset --hard disagrees

Re: I kind of killed Mercurial at Mozilla

#185

Post by RyanHamilton »

otabdeveloper4 wrote: post #178
billllll wrote: post #20

Earlier quoted context omitted.

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.

>>This means there is no friction in adopting Git at the workplace. It could be said that the virality (network effect) is higher as it spreads easier. Anything is opinionated it's just whether or not those opinions align with your internal values. It appears git aligns with you.

Re: I kind of killed Mercurial at Mozilla

#186

Post by chx »

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…

That's not a meme, many git commands have switches which make them behave wildly differently creating massive confusion.

Re: I kind of killed Mercurial at Mozilla

#187

Post by LegNeato »

glandium wrote: post #53
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…

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…

One of the Firefox rapid release designers here :-)

IIRC, topic branches were used because:

- Mercurial named branches were half baked at the time and I was advised against them by folks who knew hg better than me.

- We were already using separate clones for security update versions (3.5.x and 3.6.x) so we just kept doing the same. Some tooling could be reused.

- Rapid release was a big change and we didn't want to disrupt mozilla-central dev. Having rapid release in different clones got us out of the way and reduced the risk of negatively affecting development. m-c was the domain of developers, the rr repos were the domain of the release team.

Re: I kind of killed Mercurial at Mozilla

#188

Post by dig1 »

IshKebab wrote: post #183
dig1 wrote: post #158

Earlier quoted context omitted.

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 ;)

> Git is very good with large repos Not really. It only very recently got support for partial clones, sparse checkouts (still experimental!) `git status` daemon (only on Windows and Mac!), etc. And that's only because Microsoft is pushing it. > My guess is that people adopt monorepos because they aspire to be Google-scale, but it usually doesn't make sense for their workflow. Rubbish, it's nothing to do with wanting…

> Not really. It only very recently got support for partial clones, sparse checkouts (still experimental!) `git status` daemon (only on Windows and Mac!), etc. And that's only because Microsoft is pushing it.

Which only proves my comment that git is not designed for bigcorp view of monorepos. Kernel is monorepo and works fine.

> The reason people like monorepos is because they don't have the downsides of multirepos:

The reason people like monorepos is that they are lazy to properly organize development process. If you update library in one repo but test it in another, I'd say you need to reconsider your pipeline. But, to each their own.

Re: I kind of killed Mercurial at Mozilla

#189

Post by cookiengineer »

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...

I came here to mention that mercurial handles large binaries very well, wheras git LFS is a fustercluck of a workflow.

It's like submodules, where people 99% of the time have to add the --init --recursive flags anyways, and yet nobody cares to optimize the workflow.

I wish git had better submodules, and better binary asset folders that could be linked and cloned/fetched/pulled/pushed without having to have a complete checkout of the whole repository with all its history.

Oh, and automatic pruning would be nice because my git servers constantly run out of HDD space when I don't do git gc regularly, which oftentimes is broken in itself already.

Re: I kind of killed Mercurial at Mozilla

#190

Post by glandium »

LegNeato wrote: post #187
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…

One of the Firefox rapid release designers here :-) IIRC, topic branches were used because: - Mercurial named branches were half baked at the time and I was advised against them by folks who knew hg better than me. - We were already using separate clones for security update versions (3.5.x and 3.6.x) so we just kept doing the same. Some tooling could be reused. - Rapid release was a big change and we didn't want to d…

Hey Christian! :)
Post reply on HN