Live data from Hacker News

I kind of killed Mercurial at Mozilla

glandium.org

51–60 of 250 posts

Re: I kind of killed Mercurial at Mozilla

#51

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/

From the second article, a minor point but possibly helpful to other here, he contrasts doing everything in the terminal with stacked commits vs going to the Github UI. If people aren't aware, Github offers a cli tool[1]. I've been using it for a few months now and am finding it does make me more productive -- it's nice to be able to open up a PR directly from my terminal. I do still use the GH UI for a lot of things, but I'll often at least start in the terminal, and it also makes the transition from terminal to browser easy as many commands support the `--web` flag open up the right page for you (eg `gh repo view --web`).

[1] https://cli.github.com/

Re: I kind of killed Mercurial at Mozilla

#52
post #43
post #17

Earlier quoted context omitted.

Git has a lot of warts, but if I were to pick an alternative it would be Fossil, not Mercurial. I believe Meta’s implementation includes server components (Mononoke) that were not open-sourced, or at least not buildable without closed-source dependencies. Same with Microsoft’s fork of git that relies on a virtual filesystem, but that one is open-sourced, if for Windows, not Linux.

Mercurial is dead unfortunately. It's been stuck on Python 2. The CLI was saner than Git but it needed Python, which helped with our (better) decision to pick Fossil instead. This was 11 years ago. It's been great, it has everything you need in a single executable which can be statically compiled.

> Mercurial is dead unfortunately. It's been stuck on Python 2.

Mercurial adopted Python 3 a while ago. Not to mention, huge chunks of it have been rewritten in Rust.

Mercurial has continued to get new features like Changeset Evolution [1] that once you use it, you wonder why all version control systems don’t have it.

[1]: https://www.mercurial-scm.org/doc/evolution/

Re: I kind of killed Mercurial at Mozilla

#53

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 with "named branches").

That still leaves the question "why topic branches rather than named branches?". For the needs of the rapid release process, named branches could have been used, but weren't. I haven't tried to contact the people involved at the time to have a definite answer. It's not /that/ important, and I'm not /that/ curious.

Re: I kind of killed Mercurial at Mozilla

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

Google currently uses a fork of Mercurial as the frontend to Piper, but there is work to replace it wholesale, eventually: https://github.com/martinvonz/jj

(As a disclosure, I'm involved with and contribute to jj, but I don't work for or speak for Google in any way; the above statement is public knowledge.)

Re: I kind of killed Mercurial at Mozilla

#55
post #34

Earlier quoted context omitted.

bitbucket is worse, reviewees can resolve reviewer's comments (github has this too turns out), after file changes, comments disappear

What's wrong with reviewees marking comments resolved? That allows anyone reading to see what issues are "open" or already addressed at a glance. Code review isn't adversarial, so it's not like the reviewee is closing comments to shove bad code through and they need approvals anyway.

It's when they resolve it without verifying if their solution was good

Re: I kind of killed Mercurial at Mozilla

#57

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.

Github review is good for either zero or one round of comments. After that you can't tell what the hell is going on. It has clearly been written by people who do not themselves practice code review. Compare and contrast with Gerrit, which remains usable after many rounds of comments, in both directions, and changes. Compare also Phabricator.

Re: I kind of killed Mercurial at Mozilla

#59
post #54
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...

Google currently uses a fork of Mercurial as the frontend to Piper, but there is work to replace it wholesale, eventually: https://github.com/martinvonz/jj (As a disclosure, I'm involved with and contribute to jj, but I don't work for or speak for Google in any way; the above statement is public knowledge.)

Any comments about what it does better than git and mercurial?
Post reply on HN