8 ms·

I had no idea Google and FB were dabbling with Mercurial. I checked it out years ago, but pretty much settled on Git. What are the advantages?

fra 10y ago
They wrote about it here: https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook https://code.facebook.com/posts/218678814984400/scaling-merc...
- jcranmer 10y ago
  The big advantage to call out is that they found Mercurial much easier to add extensions to and more receptive to their issues with large monorepos. (For an idea of the scale, Facebook's repository I have heard is ~10× the size of mozilla-central, which is probably the largest public Mercurial repository.)
lucideer 10y ago
The biggest technical difference is the mostly immutable history, which is a feature or a drawback depending on who you talk to. More subjectively, most people I've chatted to about it seem to find Mercurial's interface much easier to grok / pick up as a new user than Git's (which is somewhat notorious for its quirks). There are other differences, but these stand out to me. That said, I use Git because adoption + community (and my experience with hg-git has been less successful than some... though it's been a while since I gave it a spin)
- marcinkuzminski 10y ago
  CTO of RhodeCode here. If you use phases (draft/secret/public) correctly it's really close to being mutable. For example all our devs forks are having non-publishing repositories since it's a private non-shared space. By keeping all commits as draft it's easy to do a rebase and then push new changed commits. While the main repo is publishing and once pushed commits are never mutable, also we keep a workflow that only dev forks can have multiple heads while production repo cant. IMHO it's the nicer form of mutability
  - Bjartr 10y ago
    Do you have or know of writeups describing this workflow in more detail? I'm interested in learning more.
    - ngoldbaum 10y ago
      This workflow is described in the documentation for the mercurial evolve extension: https://www.mercurial-scm.org/doc/evolution/ https://www.mercurial-scm.org/doc/evolution/
    - marcinkuzminski 10y ago
      Here's a blog post on how to use Bookmarks in Mercurial workflow using code-review. We back ported from one of the guys that works for us and described our workflow: https://rhodecode.com/blog/120/mercurial-workflow-using-bookmarks-how-to-setup-and-use https://rhodecode.com/blog/120/mercurial-workflow-using-book...
- jjnoakes 10y ago
  Can you elaborate on what you mean by immutable history, and how git lacks it?
  - lucideer 10y ago
    In git you can edit past commits and rebase, which completely destroys historical data and traces of the rebase. This can be very useful, e.g. for keeping a frequently-committed-to branch "clean" and informative by squashing commits, for removing accidentally committed sensitive credentials, etc. Mercurial, on the other hand, is architecturally set up in a way that considers the repo history to be a somewhat "sacred" truthful account. You still get the same flexibility as git if/when you need the above mutability: it's not 100% immutable, it supports local rebases, and also global mutablity via "phases" - see Marcin's post on this. In an absolute worst case scenario you can also coordinate reclones of a repo of course, but generally speaking the point is that immutability is "on by default".
    - jjnoakes 10y ago
      I'm sorry, I still don't see the distinction. It sounds like in both systems the default is immutability, with commands to override that if necessary. And by the way, doesn't git rebase not mutate history? I believe it creates a parallel history (and updates the branch and head refs to point to the new history) but the old history still exists in git's storage and can be recovered (until you GC your storage).
      - jordigh 10y ago
        In git, you `git rebase` any commit will always do whatever you tell it to do. In Mercurial, `hg rebase` will abort if you're trying to make it do something to public commits. Public commits are commits that have been shared on a publishing server. The contrast with draft commits, which are commits that have not been shared or only shared on a non-publishing server. If you really want to edit public commits, you have to manually force them back to the draft phase before you can rebase or rewrite them.
- RandomOpinion 10y ago
  To add my 2 cents, immutable history is more of an annoyance than anything. If someone checks in something by mistake that absolutely must be removed (e.g. something that contains a password), it is a considerable undertaking to actually remove that commit from the repository.
  - agentgt 10y ago
    It is not hard once you know how to do it is just not readily documented (ie histedit and force push). BTW if you checked in a password... you really should now go change that password :)
    - RandomOpinion 10y ago
      I know better than to check in passwords, thank you very much. Regrettably, some of my colleagues do not.
awinder 10y ago
If you have a ton of files inside of one gigantic repo, the work facebook is doing on mercurial might help you out. If you live in a saner world though, you'll probably benefit more from git's superior cli & tooling
- gcp 10y ago
  I think you mostly call it a "saner world" because git tooling and performance doesn't work with unified repos, so people avoid it. But it can be fixed, too, which is what Facebook and Google are doing.
- bjt 10y ago
  It's weird to hear git's cli called superior. I have much more often heard the opposite.
- arunc 10y ago
  Mercurial CLI is safe by all means! I have never lost a commit in hg. Git CLI is an abomination and is a nightmare to deal with. As a colleague of mine said once, "It is easy to develop programs than to use version control them using git".
gcp 10y ago
Much faster on Windows for large repos. Better extension system. Some like hg evolve are science fiction compared to typical git workflows. Sounds like hg absorb is similar.
cm3 10y ago
The possibility of extending the Mercurial core with a well-defined API is one major reason. In fact, most interesting features are extensions, bundled with Mercurial, and after several releases and experience, the functionality usually gets integrated into Mercurial proper (most often than not still as an extension). This is, unfortunately not an C API but Python, but it's still an advantage Mercurial has for now. Git has various efforts to build reusable libraries to write tools with, but there isn't an officially sanctioned _and_ complete one that works across all platforms. Microsoft has removed their reliance on libgit2 and shells out to git in Visual Studio now. If the git project had an official libgit, which exposed all functionality, is reused by git itself, and worked across all platforms, the situation would be in favor of git because consuming a C API is more broadly supported than, say, using a Python API inside a .Net application. tldr: Git is still faster overall, but those who want to extend a dvcs choose Mercurial for its API that exposes the data structures in a stable manner, albeit in Python, which limits use cases.
- pjmlp 10y ago
  Actually the fact that Mercurial uses Python is what made it quite usable on Windows from the get go, before Microsoft and others bothered to step up and improve the experience. As for using Python on .NET, that is what Iron Python is for.
  - cm3 10y ago
    Of course Python as an abstraction layer made it more readily available on Windows and allowed allocation of developer resources to hgtk, including a Windows Explorer extension. Still, despite its flaws, C is the common layer we have to expose an API that you want to be consumed everywhere. That, or a message passing interface with a client/server architecture. A client/server design may lead to zombie servers, while a tightly coupled C API might crash your application, though you can isolate the C API consumer in a supervised and automatically restarted server you talk to with messages, so that's the more flexible API to have. The Rust rewrite of parts of Mercurial by Facebook is a no-brainer and given the possibility of GC-less C API in Rust, I wouldn't be surprised if a built-in-Rust C API for Mercurial were to follow. I don't like Rust when compared to high-level languages, but it's a viable C replacement with compile-time exclusion of certain bug classes, so I can get behind such a project. That said, the soundness bugs reported on github are worrisome, so I wouldn't trust Rust's checker to be correct or exhaustive, just yet. It's still a step up from C, that's undeniable.
kyrra 10y ago
1) The .git directory doesn't play nicely with mono-repos. Since all files are just hashed files that live in the .git dir, knowing which files in there are part of a subtree is hard. On the other side, Mercurial .hg dir uses a tree structure to track files, so you can do things like NarrowHG[0]. 2) As well, Git has multiple client implementation (like git, egit, jgit, etc...). Adding new features is a bit more complicated as all the implementations need to add them before they can be more widely used. Mercurial has one implementation that everyone uses. So new features are easier to add. 3) The .git structure is simple, which is great, but it's become the API for git in a way. While mercurial explicitly says you should never rely on the structure of the .hg directory. If you want to interact with the .hg dir from other software, you should either issue 'hg' command or start up a command server[1] to talk with it. So it creates a cleaner API barrier. Because of this, the Mercurial team can make changes to the .hg dir to better serve different needs (like those of a mono-repo), without breaking the world. [0] https://bitbucket.org/Google/narrowhg https://bitbucket.org/Google/narrowhg [1] https://www.mercurial-scm.org/wiki/CommandServer https://www.mercurial-scm.org/wiki/CommandServer
- avar 10y ago
  The .git file format has also changed multiple times, packed refs, multiple pack file formats etc. There's even WIP ref backends now which store the whole thing in some embedded database format.
  - alblue 10y ago
    There is no ".git" file. It's a directory with a lot of files. Some of the packing has been storage optimisations but the logical model (objects identified by hash) has remained the same throughout. The nice thing about this is you can present the same logical model while being flexible about the way that model is persisted, unlike Mercurial which has a fixed file format upon which operations are based.
- bedros 10y ago
  narrowhg looks like a good replacement for subrepo, thanks for the tip
pjmlp 10y ago
A sane distributed source control system implemented in Python. I am still disappointed that Git won.
- shoover 10y ago
  Agreed. And yet it is encouraging to see the continued investment and upstream engagement by Facebook and Mozilla. (I knew Facebook and Mozilla were heavily invested; I'm not sure what Google's involvement is since code.google.com was abandoned.) Things could get more competitive in terms of global mindshare if more Facebook engineers (some of whom the OP mentioned have forgotten how to use git) start speaking out in favor of Mercurial.
  - ngoldbaum 10y ago
    Google is working on adding mercurial as a frontend for their repository management system (Piper) and development environment (CitC).
- geodel 10y ago
  Also C won, Unix won, Android won. Seems technical subpar options are better business options.
  - pjmlp 10y ago
    You forgot JavaScript and PHP.
- rjbwork 10y ago
  Depends on your definition of won, I guess...fourth job in a row using Hg. I've never used git professionally, just for OSS stuff.

fra 10y ago

They wrote about it here: https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook https://code.facebook.com/posts/218678814984400/scaling-merc...

jcranmer 10y ago
The big advantage to call out is that they found Mercurial much easier to add extensions to and more receptive to their issues with large monorepos. (For an idea of the scale, Facebook's repository I have heard is ~10× the size of mozilla-central, which is probably the largest public Mercurial repository.)

lucideer 10y ago

The biggest technical difference is the mostly immutable history, which is a feature or a drawback depending on who you talk to. More subjectively, most people I've chatted to about it seem to find Mercurial's interface much easier to grok / pick up as a new user than Git's (which is somewhat notorious for its quirks). There are other differences, but these stand out to me. That said, I use Git because adoption + community (and my experience with hg-git has been less successful than some... though it's been a while since I gave it a spin)

marcinkuzminski 10y ago
CTO of RhodeCode here. If you use phases (draft/secret/public) correctly it's really close to being mutable. For example all our devs forks are having non-publishing repositories since it's a private non-shared space. By keeping all commits as draft it's easy to do a rebase and then push new changed commits. While the main repo is publishing and once pushed commits are never mutable, also we keep a workflow that only dev forks can have multiple heads while production repo cant. IMHO it's the nicer form of mutability
- Bjartr 10y ago
  Do you have or know of writeups describing this workflow in more detail? I'm interested in learning more.
  - ngoldbaum 10y ago
    This workflow is described in the documentation for the mercurial evolve extension: https://www.mercurial-scm.org/doc/evolution/ https://www.mercurial-scm.org/doc/evolution/
  - marcinkuzminski 10y ago
    Here's a blog post on how to use Bookmarks in Mercurial workflow using code-review. We back ported from one of the guys that works for us and described our workflow: https://rhodecode.com/blog/120/mercurial-workflow-using-bookmarks-how-to-setup-and-use https://rhodecode.com/blog/120/mercurial-workflow-using-book...
jjnoakes 10y ago
Can you elaborate on what you mean by immutable history, and how git lacks it?
- lucideer 10y ago
  In git you can edit past commits and rebase, which completely destroys historical data and traces of the rebase. This can be very useful, e.g. for keeping a frequently-committed-to branch "clean" and informative by squashing commits, for removing accidentally committed sensitive credentials, etc. Mercurial, on the other hand, is architecturally set up in a way that considers the repo history to be a somewhat "sacred" truthful account. You still get the same flexibility as git if/when you need the above mutability: it's not 100% immutable, it supports local rebases, and also global mutablity via "phases" - see Marcin's post on this. In an absolute worst case scenario you can also coordinate reclones of a repo of course, but generally speaking the point is that immutability is "on by default".
  - jjnoakes 10y ago
    I'm sorry, I still don't see the distinction. It sounds like in both systems the default is immutability, with commands to override that if necessary. And by the way, doesn't git rebase not mutate history? I believe it creates a parallel history (and updates the branch and head refs to point to the new history) but the old history still exists in git's storage and can be recovered (until you GC your storage).
    - jordigh 10y ago
      In git, you `git rebase` any commit will always do whatever you tell it to do. In Mercurial, `hg rebase` will abort if you're trying to make it do something to public commits. Public commits are commits that have been shared on a publishing server. The contrast with draft commits, which are commits that have not been shared or only shared on a non-publishing server. If you really want to edit public commits, you have to manually force them back to the draft phase before you can rebase or rewrite them.
RandomOpinion 10y ago
To add my 2 cents, immutable history is more of an annoyance than anything. If someone checks in something by mistake that absolutely must be removed (e.g. something that contains a password), it is a considerable undertaking to actually remove that commit from the repository.
- agentgt 10y ago
  It is not hard once you know how to do it is just not readily documented (ie histedit and force push). BTW if you checked in a password... you really should now go change that password :)
  - RandomOpinion 10y ago
    I know better than to check in passwords, thank you very much. Regrettably, some of my colleagues do not.

awinder 10y ago

If you have a ton of files inside of one gigantic repo, the work facebook is doing on mercurial might help you out. If you live in a saner world though, you'll probably benefit more from git's superior cli & tooling

gcp 10y ago
I think you mostly call it a "saner world" because git tooling and performance doesn't work with unified repos, so people avoid it. But it can be fixed, too, which is what Facebook and Google are doing.
bjt 10y ago
It's weird to hear git's cli called superior. I have much more often heard the opposite.
arunc 10y ago
Mercurial CLI is safe by all means! I have never lost a commit in hg. Git CLI is an abomination and is a nightmare to deal with. As a colleague of mine said once, "It is easy to develop programs than to use version control them using git".

gcp 10y ago

Much faster on Windows for large repos. Better extension system. Some like hg evolve are science fiction compared to typical git workflows. Sounds like hg absorb is similar.

cm3 10y ago

The possibility of extending the Mercurial core with a well-defined API is one major reason. In fact, most interesting features are extensions, bundled with Mercurial, and after several releases and experience, the functionality usually gets integrated into Mercurial proper (most often than not still as an extension). This is, unfortunately not an C API but Python, but it's still an advantage Mercurial has for now. Git has various efforts to build reusable libraries to write tools with, but there isn't an officially sanctioned _and_ complete one that works across all platforms. Microsoft has removed their reliance on libgit2 and shells out to git in Visual Studio now. If the git project had an official libgit, which exposed all functionality, is reused by git itself, and worked across all platforms, the situation would be in favor of git because consuming a C API is more broadly supported than, say, using a Python API inside a .Net application. tldr: Git is still faster overall, but those who want to extend a dvcs choose Mercurial for its API that exposes the data structures in a stable manner, albeit in Python, which limits use cases.

pjmlp 10y ago
Actually the fact that Mercurial uses Python is what made it quite usable on Windows from the get go, before Microsoft and others bothered to step up and improve the experience. As for using Python on .NET, that is what Iron Python is for.
- cm3 10y ago
  Of course Python as an abstraction layer made it more readily available on Windows and allowed allocation of developer resources to hgtk, including a Windows Explorer extension. Still, despite its flaws, C is the common layer we have to expose an API that you want to be consumed everywhere. That, or a message passing interface with a client/server architecture. A client/server design may lead to zombie servers, while a tightly coupled C API might crash your application, though you can isolate the C API consumer in a supervised and automatically restarted server you talk to with messages, so that's the more flexible API to have. The Rust rewrite of parts of Mercurial by Facebook is a no-brainer and given the possibility of GC-less C API in Rust, I wouldn't be surprised if a built-in-Rust C API for Mercurial were to follow. I don't like Rust when compared to high-level languages, but it's a viable C replacement with compile-time exclusion of certain bug classes, so I can get behind such a project. That said, the soundness bugs reported on github are worrisome, so I wouldn't trust Rust's checker to be correct or exhaustive, just yet. It's still a step up from C, that's undeniable.

kyrra 10y ago

1) The .git directory doesn't play nicely with mono-repos. Since all files are just hashed files that live in the .git dir, knowing which files in there are part of a subtree is hard. On the other side, Mercurial .hg dir uses a tree structure to track files, so you can do things like NarrowHG[0]. 2) As well, Git has multiple client implementation (like git, egit, jgit, etc...). Adding new features is a bit more complicated as all the implementations need to add them before they can be more widely used. Mercurial has one implementation that everyone uses. So new features are easier to add. 3) The .git structure is simple, which is great, but it's become the API for git in a way. While mercurial explicitly says you should never rely on the structure of the .hg directory. If you want to interact with the .hg dir from other software, you should either issue 'hg' command or start up a command server[1] to talk with it. So it creates a cleaner API barrier. Because of this, the Mercurial team can make changes to the .hg dir to better serve different needs (like those of a mono-repo), without breaking the world. [0] https://bitbucket.org/Google/narrowhg https://bitbucket.org/Google/narrowhg [1] https://www.mercurial-scm.org/wiki/CommandServer https://www.mercurial-scm.org/wiki/CommandServer

avar 10y ago
The .git file format has also changed multiple times, packed refs, multiple pack file formats etc. There's even WIP ref backends now which store the whole thing in some embedded database format.
- alblue 10y ago
  There is no ".git" file. It's a directory with a lot of files. Some of the packing has been storage optimisations but the logical model (objects identified by hash) has remained the same throughout. The nice thing about this is you can present the same logical model while being flexible about the way that model is persisted, unlike Mercurial which has a fixed file format upon which operations are based.
bedros 10y ago
narrowhg looks like a good replacement for subrepo, thanks for the tip

pjmlp 10y ago

A sane distributed source control system implemented in Python. I am still disappointed that Git won.

shoover 10y ago
Agreed. And yet it is encouraging to see the continued investment and upstream engagement by Facebook and Mozilla. (I knew Facebook and Mozilla were heavily invested; I'm not sure what Google's involvement is since code.google.com was abandoned.) Things could get more competitive in terms of global mindshare if more Facebook engineers (some of whom the OP mentioned have forgotten how to use git) start speaking out in favor of Mercurial.
- ngoldbaum 10y ago
  Google is working on adding mercurial as a frontend for their repository management system (Piper) and development environment (CitC).
geodel 10y ago
Also C won, Unix won, Android won. Seems technical subpar options are better business options.
- pjmlp 10y ago
  You forgot JavaScript and PHP.
rjbwork 10y ago
Depends on your definition of won, I guess...fourth job in a row using Hg. I've never used git professionally, just for OSS stuff.