Live data from Hacker News

I kind of killed Mercurial at Mozilla

glandium.org

21–30 of 250 posts

Re: I kind of killed Mercurial at Mozilla

#21
post #4

Earlier quoted context omitted.

> I also would expect that Github eventually will also offer mercurial repos. How come? That seems highly unlikely to me, especially when you consider that one of their larger competitors (Bitbucket) had Mercurial support for a long time and then removed it.

That change was so dumb. Mercurial support was the bit that put them as something different from github. Once they didn't have it anymore, why would anyone use them at all?

I'm sure they knew what they did. They probably primarily had git users on the service, and the motivation to use Bitbucket is most likely because you already pay for other Atlassian products.

Re: I kind of killed Mercurial at Mozilla

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

Meta's fork/rewrite of hg, Sapling hasn't gone anywhere yet because it needs EdenFS and Mononoke that aren't yet/maybe never FOSS. It's only called hg internally because of legacy reasons but it's completely different. Microsoft hired a git maintainer to improve large repo performance and so it's better than it was.

I’ve been using the sapling CLI as my frontend with github as my backend and finding it quite delightful - all the UX niceness from mercurial (and then some), while still being totally compatible with the rest of my team :)

Re: I kind of killed Mercurial at Mozilla

#23
I've heard this point of view many times, but cannot find an extensive explanation of it. Could anyone elaborate on the issue with the GitHub review UI/UX?

> I hate the GitHub review UI with a passion. At least, right now, GitHub PRs are not a viable option for Mozilla [...] the more general shortcomings in the review UI.

Re: I kind of killed Mercurial at Mozilla

#24
post #5
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...

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

As somebody who has actually been using Sapling (because it provides a much saner UI and mental model than git), the git compatibility of Sapling is at best so-so. It feels more like a stopgap solution while they're evolving their own backend (which I'm pretty sure they use internally, because git just doesn't scale to FB monorepo size and doesn't support their rebase-on-push operation). LFS flat-out doesn't work with Sapling. Force pushing after an amend or rebase is still cumbersome, because you need to explicitly specify (again) the branch you are pushing to. And I'm not sure how bad the file descriptor problem still is that you have (had?) with large repos or submodules [1]; there was a new release recently, but I haven't actually stress-tested that.

[1] At least some of that may be due to file descriptor leaks: https://github.com/facebook/sapling/issues/464

Re: I kind of killed Mercurial at Mozilla

#25

I've heard this point of view many times, but cannot find an extensive explanation of it. Could anyone elaborate on the issue with the GitHub review UI/UX? > I hate the GitHub review UI with a passion. At least, right now, GitHub PRs are not a viable option for Mozilla [...] the more general shortcomings in the review UI.

I know people who express similar feelings. Usually it is shorthand for "I would prefer stacked diffs" or similar.

Two blog posts I've seen people point at:

* https://mitchellh.com/writing/github-changesets

* https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/

Re: I kind of killed Mercurial at Mozilla

#26
post #4

Earlier quoted context omitted.

> I also would expect that Github eventually will also offer mercurial repos. How come? That seems highly unlikely to me, especially when you consider that one of their larger competitors (Bitbucket) had Mercurial support for a long time and then removed it.

That change was so dumb. Mercurial support was the bit that put them as something different from github. Once they didn't have it anymore, why would anyone use them at all?

So since you are knowledgeable about the fact that this decision was "dumb", you must also know approximately what proportion of their users were dependent on hg for their workflow ? My priors would put it at less - likely far less - than 1%. But please share your knowledge.

Re: I kind of killed Mercurial at Mozilla

#27
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 knew the guy who wanted Google Code to be Mercurial based; he pretty much just did it because he liked Python and therefore thought anything written in Python was good.

Re: I kind of killed Mercurial at Mozilla

#28

I've heard this point of view many times, but cannot find an extensive explanation of it. Could anyone elaborate on the issue with the GitHub review UI/UX? > I hate the GitHub review UI with a passion. At least, right now, GitHub PRs are not a viable option for Mozilla [...] the more general shortcomings in the review UI.

One point: if you are re-reviewing, other platforms (e.g. Phabricator, Gerrit) have much more developed ways to compare changes relative to one another.

Re: I kind of killed Mercurial at Mozilla

#29
post #4

Earlier quoted context omitted.

> I also would expect that Github eventually will also offer mercurial repos. How come? That seems highly unlikely to me, especially when you consider that one of their larger competitors (Bitbucket) had Mercurial support for a long time and then removed it.

That change was so dumb. Mercurial support was the bit that put them as something different from github. Once they didn't have it anymore, why would anyone use them at all?

One huge advantage for them compared to GitHub is that they offer an on-prem version. That is much more relevant than Hg support of all things.

It also gets bundled with Jira and Confluence.

Re: I kind of killed Mercurial at Mozilla

#30
post #9

i kind of wonder why there has never been an "hghub", given that i've always liked hg rather than git. but i guess it is the torvalds connection?

Because you never wrote it. The curse of open source.

By the time github came about, git already had a lot more mindshare than hg. While hg wasn't yet clearly an also ran, it was clearly the less popular solution, and many open source tools started supporting git but either not supporting hg, or if they did it was an afterthought and often the maintainers broke something hg without noticing and then releasing with broken hg support.

Post reply on HN