Hacker News Reader

Comment by Annatar | Hacker News Reader

Mercurial is much easier to understand and use than git, and for the most part has feature parity with it. The only drawback was the decision to implement it in Python, which makes it very slow for large codebases with gigabytes in binary files. However, I'm given to understand that core performance parts are being re-implemented in C.

View on HN

What's interesting is that Git is fast up until it isn't, and it's written in such a way that fixing performance issues that do pop up is hard (or extend the software when more custom behavior is needed).

That's why Facebook chose to just fix the slow parts of hg[1], rather than fix the slow parts of git, to build a VCS which would scale with its codebase.

[1]: https://code.fb.com/core-data/scaling-mercurial-at-facebook/

> That's why Facebook chose to just fix the slow parts of hg[1], rather than fix the slow parts of git, to build a VCS which would scale with its codebase.

On the other hand, Google seems to successfully use Git in the same way.

Google does not use Git for its monorepo.

Afaik Googlers can use git client-side. The central repo is certainly not git though.

Also parts of Google, like Chrome, Android, and Go, do use git.

Or Microsoft (Windows is using Git).

With extensions to make it bearable for their code size.

Just as Facebook does for Hg: https://bitbucket.org/facebook/hg-experimental

Microsoft wrote a new filesystem driver for git because extending the code itself was too difficult...

They also worked a lot on Git itself.

Several parts of mercurial are implemented in C. There is an ongoing plan to recode some of the core in Rust:

https://www.mercurial-scm.org/wiki/OxidationPlan

Recoding it in Rust would make Mercurial instantaneously unportable to any operating system which does not have a Rust compiler.

What kind of platforms would you be worried about missing out on. Rust platform support[1] looks pretty solid, but of course isn't that of, say, C, but in practice I am not aware of (but would love to learn about!) Use cases for running a vcs on more obscure platforms.

[1] https://forge.rust-lang.org/platform-support.html

"I don't recognize your platform.

Rust runs on Windows, Linux, Mac OS X, FreeBSD and NetBSD. If you are on one of these platforms and are seeing this then please report an issue, along with the following values:

  navigator.platform:
    SunOS i86pc
  navigator.appVersion:
    5.0 (X11)

To install Rust, if you are running Unix, run the following in your terminal, then follow the onscreen instructions.

  curl https://sh.rustup.rs -sSf | sh"

...and running that gives:

  curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

And I am running UNIX, a true, AT&T System V, Release 4.0 UNIX: Solaris 10 on i86pc.

I don't want to have to give up Mercurial just because someone somewhere is trying to be trendy by rewriting parts of it in Rust, because he thinks that's all the rage now.

That's a curl error to do with ssl versions, try using something other than curl to download it.

Actually, after a bit more research it looks like Solaris is a lower tier platform, which means there are no prebuilt binaries that are available, but it should work if you build it yourself.

I've been using Mercurial on Solaris 10 since 2006.

What you're saying is that if I had to upgrade to a newer version of Mercurial which used software written in Rust, I'd have to bootstrap and port an entire programming language, just to use a newer version of my revision control software?

That would be entirely up to the maintainers of Mercurial if they would distribute pre-built packages for Solaris 10. If you're concerned, you'd be better off making the case to them to do just that.

It's about the concept, not about Mercurial per se: nobody should be forced to have to bootstrap and port an entire programming language just to be able to use a newer version of an application. That's insane and irresponsible, not to mention selfish.

How strongly are you claiming "nobody" here? Does the cost of supporting niche platforms ever get too high in your mind? If so, what is an appropriate line to draw for cutting off explicit support?

Hopefully, it would increase pressure to actually port it there or to use another compiler like mrustc[0]

[0] https://github.com/thepowersgang/mrustc

> Mercurial is much easier to understand and use than git

I simply do not find this to be true. I've used git for years and tried to use hg to participate in a project and I straight-up just could not understand its branching model and how exactly I was supposed to use that tool. I ended up maintaining my work in a git repository and very carefully doing individual commits and a push in the hg repository only at the very end of a long work period. My daily work remained in git because I could not for the life of me understand how people work with that tool with regards to local branches and squashing. (Which, sorry, I cannot do without.)

> I ended up maintaining my work in a git repository and very carefully doing individual commits and a push in the hg repository only at the very end of a long work period. My daily work remained in git because I could not for the life of me understand how people work with that tool with regards to local branches and squashing.

Local branches are fairly simple - use the phase command to mark your changesets as secret.

As for squashing... It's more complex, and not so easy, though doable, because Mercurial discourages it. (Though the solutions are on their wiki [0], and various extensions can simplify it for you.)

[0] https://www.mercurial-scm.org/wiki/ConcatenatingChangesets

Use Mercurial histedit extension, this is a game changer on all operations. Works like git rebase -i but just better combined with phases. So most likely your not-yet-pushed commits are marked as draft, so you can run hg histedit.

We use this ALIAS:

histamend = !$HG histedit $(hg log -l1 -r '(draft() or secret()) and branch(.)' --template={rev})

This shows you option to drop/squash re-order/edit messages on all draft or secret commits in the current checkout branch

Or just use evolve + topics and you can squash/fold in pretty much the same way as git, plus you hg obslog you can still reference the root commits.

Mercurial is much easier to understand and use than git, and for the most part has feature parity with it.

There isn’t a Git workflow that can’t be done using Mercurial; in fact, the Mercurial team from what I’ve read and listened to via podcasts, has intentionally added features to accommodate Git-style workflows, since developers obviously like and are using them.

Reply on news.ycombinator.com