5 ms·

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

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.

stevekemp 8y ago
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 https://www.mercurial-scm.org/wiki/OxidationPlan
- Annatar 8y ago
  Recoding it in Rust would make Mercurial instantaneously unportable to any operating system which does not have a Rust compiler.
  - dmytrish 8y ago
    Hopefully, it would increase pressure to actually port it there or to use another compiler like mrustc[0] [0] https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
  - Bjartr 8y ago
    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 https://forge.rust-lang.org/platform-support.html
    - Annatar 8y ago
      "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.
      - Bjartr 8y ago
        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.
        Annatar 8y ago
        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?
        Bjartr 8y ago
        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.
        Annatar 8y ago
        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.
dymk 8y ago
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/ https://code.fb.com/core-data/scaling-mercurial-at-facebook/
- whyever 8y ago
  > 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.
  - jhasse 8y ago
    Or Microsoft (Windows is using Git).
    - pjmlp 8y ago
      With extensions to make it bearable for their code size.
      - jhasse 8y ago
        Just as Facebook does for Hg: https://bitbucket.org/facebook/hg-experimental https://bitbucket.org/facebook/hg-experimental
    - yoden 8y ago
      Microsoft wrote a new filesystem driver for git because extending the code itself was too difficult...
      - jhasse 8y ago
        They also worked a lot on Git itself.
radarsat1 8y ago
> 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.)
- shakna 8y ago
  > 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 https://www.mercurial-scm.org/wiki/ConcatenatingChangesets
  - marcinkuzminski 8y ago
    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
    - eire1130 8y ago
      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.
alwillis 8y ago
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.

stevekemp 8y ago

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 https://www.mercurial-scm.org/wiki/OxidationPlan

Annatar 8y ago
Recoding it in Rust would make Mercurial instantaneously unportable to any operating system which does not have a Rust compiler.
- dmytrish 8y ago
  Hopefully, it would increase pressure to actually port it there or to use another compiler like mrustc[0] [0] https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
- Bjartr 8y ago
  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 https://forge.rust-lang.org/platform-support.html
  - Annatar 8y ago
    "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.
    - Bjartr 8y ago
      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.
      - Annatar 8y ago
        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?
        Bjartr 8y ago
        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.
        Annatar 8y ago
        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.

dymk 8y ago

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/ https://code.fb.com/core-data/scaling-mercurial-at-facebook/

whyever 8y ago
> 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.
- jhasse 8y ago
  Or Microsoft (Windows is using Git).
  - pjmlp 8y ago
    With extensions to make it bearable for their code size.
    - jhasse 8y ago
      Just as Facebook does for Hg: https://bitbucket.org/facebook/hg-experimental https://bitbucket.org/facebook/hg-experimental
  - yoden 8y ago
    Microsoft wrote a new filesystem driver for git because extending the code itself was too difficult...
    - jhasse 8y ago
      They also worked a lot on Git itself.

radarsat1 8y ago

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

shakna 8y ago
> 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 https://www.mercurial-scm.org/wiki/ConcatenatingChangesets
- marcinkuzminski 8y ago
  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
  - eire1130 8y ago
    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.

alwillis 8y ago

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.