6 ms·

Key paragraph for us mere mortals: "In my time with Mercurial, I have seen it grow in fascinating ways. These include the concept of changeset evolution coming

Key paragraph for us mere mortals: "In my time with Mercurial, I have seen it grow in fascinating ways. These include the concept of changeset evolution coming to life and the announcement of both Facebook and Google choosing Mercurial over Git. The future of Mercurial is that of scalability and because of that, I believe the best days of Mercurial are ahead." Is it time to give Mercurial another shot? I first migrated from SVN to Mercurial way back when - but after the massive increase in Git's popularity I bit the bullet and switched. What does Mercurial have over Git today?

sampo 12y ago
> What does Mercurial have over Git today? There exists no easy tutorial, that takes a beginner up to speed with git. You need to read almost a book length of material and familiarize yourself with some of the git's internals, and to some extent build your own mental model of git by experimentation, before you can use git without regular wtf-moments. Well, there is also no tutorial that would provide the same level of understanding of the internals of Mercurial, but by some magic it seems that beginners do not need to acquire the same depth of understanding of Mercurial that they need to acquire about git, before they can start to work with Mercurial without wtf's and frustration. Once you have a solid understanding of how DVCS's work, you can use both Mercurial and git without problems. But if you need to bring a bunch of beginners up to speed, somehow it goes easier with Mercurial. At least, this is my experience. If someone else has experience in training teams to start using a DVCS, and has compared both git and Mercurial, and has opposite experiences, I'd be interested to hear.
- tjradcliffe 12y ago
  I have had the same experience as you. I used git for a couple of years and definitely had regular wtf moments. Switched to Mercurial and they just went away. The complexity and counter-intuitive (to me, at least) nature of git's model was a major barrier to entry. I still use git now and then because github is so popular, but for a small team on a moderate-sized project I really prefer Mercurial for its ease of use.
- Touche 12y ago
  I simply don't agree with this. There's nothing wtf about git add, git commit, git push. Those are the commands that normal developers use. Maybe git reflog has issues but 90% of people are never going to come across them.
  - worklogin 12y ago
    Nothing about that deals with collaboration. fetch/merge/pull/remotes can be pretty confusing without really wrapping your head around it.
    - Touche 12y ago
      What is wtf about git pull? > git pull origin master (fix conflicts) > git commit That's it.
      - dfabulich 12y ago
        1) Pull creates a merge commit. Why? 2) What's a fast forward? 3) What's a tracking branch?
        somebehemoth 12y ago
        1) So you can revert the merge very easily. 2) Merging without a commit. 3) A branch on a remote server that you have a copy of locally and you want to keep track of the status of remote against the local copy (who's behind and who is ahead?). This is my basic understanding in terms of how I use git. I like Mercurial too and don't have a horse in this race.
        mpdehaan2 12y ago
        While this somewhat underscores some complexity in git, here's something I wrote trying to explain to others why and how to avoid those merge commits: http://michaeldehaan.net/post/116465000577/understanding-when-to-use-git-rebase http://michaeldehaan.net/post/116465000577/understanding-whe...
- DigitalJack 12y ago
  I use git every day, all day at work. It is absolutely integral to my workflow, and the only thing I know about its internals comes from people posting about them here. Needing to know anything about git's internals to be able to use git is FUD.
- chralieboy 12y ago
  Git Immersion (http://gitimmersion.com/ http://gitimmersion.com/) is great for getting up to speed as a beginner.
gecko 12y ago
It has greater extensibility (both in protocol and the code itself), which is why Facebook and Google are looking at it in the first place: it's possible to hook into it in such a way that you can make it scale to ridiculous sizes (see e.g. https://bitbucket.org/facebook/remotefilelog https://bitbucket.org/facebook/remotefilelog) cleanly, in a fully backwards-compatible way, without forking the product. So it's worth looking at for at least that reason alone. Beyond that, though, the team itself is leveraging that extensibility to continue to evolve Mercurial in new directions. Years ago, I was able to ship a third-party largefiles extension that worked similar to the GitHub external files thing launched a few weeks ago, and was able to get it integrated into Mercurial easily, where it was heavily used for years by people in the games industry. The team took "bookmarks" (Git-style branches) under its wing when they proved valuable, and have now added a ton of behavior to improve bookmark workflows. They can even add huge new features. the big one that Git lacks is changeset evolution. Evolution allows you to get all of the benefits of rebasing and squashing, and all the benefits of a traditional DVCS merge-based workflow. Specifically, you can see all the previous versions of a given changeset, but those versions don't need to clutter up the history unless you're specifically interested. This means you're dramatically less likely to lose critical forensics information over the course of developing a new feature, and much more likely to be able to sanely see where, over the course of several rebases, you mucked up how a chunk of code actually worked.
- glandium 12y ago
  > it's possible to hook into it in such a way that you can make it scale to ridiculous sizes (see e.g. https://bitbucket.org/facebook/remotefilelog https://bitbucket.org/facebook/remotefilelog) cleanly, in a fully backwards-compatible way, without forking the product. That's not entirely true. For instance, some of the scaling is going to require a new manifest format that is not going to be backwards compatible.
jordigh 12y ago
Oh, boy, I'll try to answer, and perhaps later turn this into a FAQ for our wiki: * revsets -- feature-rich DSL for querying your history, my presentation on them: https://www.youtube.com/watch?feature=player_embedded&v=NSLvERZQSok#t=973 https://www.youtube.com/watch?feature=player_embedded&v=NSLv... * templates -- the output of just about any hg command can be customised: http://mercurial.selenic.com/wiki/GenericTemplatingPlan http://mercurial.selenic.com/wiki/GenericTemplatingPlan http://jordi.inversethought.com/blog/customising-mercurial-like-a-pro/ http://jordi.inversethought.com/blog/customising-mercurial-l... * Evolve -- safely rewrite commits as a team, a safe replacement for `git push --force`: https://www.youtube.com/watch?v=4OlDm3akbqg https://www.youtube.com/watch?v=4OlDm3akbqg * Very easy to write extensions: http://mercurial.selenic.com/wiki/UsingExtensions http://mercurial.selenic.com/wiki/UsingExtensions * Mercurial scales well to gigantic monolithic repos: https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc... That's all I can think of for now.
- twic 12y ago
  Oh god, revsets. When i was able to use Mercurial (via hgsubversion and hg-git), i used revsets constantly, to ferret out all sorts of useful knowledge from the repository. My Git-using colleagues thought i was some kind of wizard. I switched jobs, and now i just use Git. I miss revsets so much.
- gnuvince 12y ago
  In that lightning talk, were you actually typing or were you playing an accelerated recording of you typing previously? Cause it seems like you type at something like 300 wpm or something insane like that!
  - jordigh 12y ago
    Everyone always asks me that. It's a hack that someone else later turned into: http://doitlive.readthedocs.org/en/latest/ http://doitlive.readthedocs.org/en/latest/ I hope you were able to pay attention to the talk instead of the gimmick.
ngoldbaum 12y ago
One short answer: changeset phases and evolution http://mercurial.selenic.com/wiki/Phases http://mercurial.selenic.com/wiki/Phases http://mercurial.selenic.com/wiki/ChangesetEvolution http://mercurial.selenic.com/wiki/ChangesetEvolution The latter is embodied in the Evolve extension, which I use for day-to-day stuff and find incredibly useful. http://mercurial.selenic.com/wiki/EvolveExtension http://mercurial.selenic.com/wiki/EvolveExtension The reason Google and Facebook are interested in mercurial is based on the remotefilelog extension: http://mercurial.selenic.com/wiki/ScaleMercurial http://mercurial.selenic.com/wiki/ScaleMercurial https://bitbucket.org/facebook/remotefilelog https://bitbucket.org/facebook/remotefilelog https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc... Performance on huge monolithic repositories like the ones Facebook, Google, and Mozilla work with is actively considered by the mercurial developers when integrating new features.
kyrra 12y ago
To add to the Google bit, from Facebook's F8 there was this interesting tidbit (source[0]): > Quote from Google: "We're excited about the work Facebook is doing with Mercurial and glad to be collaborating with Facebook on Mercurial development." (Well, I guess the cat is finally out of the bag: Google is working on Mercurial. This was kind of an open secret for months. But I guess now it is official.) As well, if you search the Mercurial-devel mailing list[1], you'll see that Google engineers has been committing to Mercurial for a bit now. (Looks like they started in Aug 2014, and really picked up in Nov 2014). [0] http://gregoryszorc.com/blog/2015/03/28/notes-from-facebook%27s-developer-infrastructure-at-scale-f8-talk/ http://gregoryszorc.com/blog/2015/03/28/notes-from-facebook%... [1] http://mercurial.markmail.org/search/?q=list%3Acom.selenic.mercurial-devel+%40google.com http://mercurial.markmail.org/search/?q=list%3Acom.selenic.m...
rifung 12y ago
I heard that Facebook picked Mercurial because it was easier for them to make it work at their scale. On the other hand, the company I currently work for also uses Mercurial, but all the developers besides maybe the founder (I haven't asked) prefer Git. I don't know the specifics about why everyone feels that way but from what I gather it has to do with branching being easier.
- jurip 12y ago
  I've come to the conclusion that git got branches right. The idea of permanent metadata for branches is appealing, but repository-wide single namespace is bit of a PITA in some circumstance. Mercurial's bookmarks are the same as git's branches, but Bitbucket support is lacking. The other big thing git has is startup speed. Python is slow. Something like chg helps, but it's a workaround.
  - ArneBab 12y ago
    I only see startup problems with hg when on the university cluster, where the filesystem is slow when accessing many files (metadata access). Startup speed for hg is on my machine below 100ms, less than the time most people need to type a single letter.
  - rbehrends 12y ago
    I am not really happy with either Git's or Mercurial's solution. Git's branches introduce too much fragility in the system for end user consumption (because branches are responsible for both naming and keeping commits alive) and do not allow you to describe sets of commits (nor is there an alternative feature for that), Mercurial's branches are too permanent in that they cannot even be renamed (well, there's an extension for that, but that's not without issues). Mercurial bookmarks still do not allow you to label sets of commits, but at least aren't responsible for the liveness of a commit. In practice, I like both Fossil's and Bazaar's model better.
    - Skinney 12y ago
      What do you mean by a "set of commits". Why not just have topic branches? Branches isn't the only thing that keeps commits alive, you also got the reflog and tags. I have a hard time understanding why you would want to keep something alive that isn't reachable from the history.
rbehrends 12y ago
> What does Mercurial have over Git today? Aside from what others have mentioned, the biggest thing for me personally is hg share, i.e. the ability to have two or more independent checkouts of the same repository. Git does not really support this. Your options are (1) git-new-workdir, which is not safe and can lose data and (2) doing a complete clone, which is cumbersome, because you can't directly diff/merge against branches in the other repository, but have to push/fetch first. Disclaimer: I'm one of the strange people who (by preference) still uses Bazaar over Git and Mercurial whenever possible, so that may skew my preferences.
wwb099 12y ago
TortoiseHG. SourceTree is getting to be OK, at least on windows but git gui apps suck. And if you are doing anything non-trivial and non-automated then gui SCM clients are just fine kids.
Too 12y ago
> What does Mercurial have over Git today? Not related to the core product but still very important for the experience: A decent Windows gui, tortiose hg. I have tried all the guis for git, both commercial and free, and they all suck rats ass. Either they are slow, they only support github, they look like shit, they only support the most basic commit operations, they can't show the diff between selected revisions, they destroy your merges and simply make everything related to source control a pita. There are many many of them available that can do some of the things I listed above but none that does all of it.

sampo 12y ago

> What does Mercurial have over Git today? There exists no easy tutorial, that takes a beginner up to speed with git. You need to read almost a book length of material and familiarize yourself with some of the git's internals, and to some extent build your own mental model of git by experimentation, before you can use git without regular wtf-moments. Well, there is also no tutorial that would provide the same level of understanding of the internals of Mercurial, but by some magic it seems that beginners do not need to acquire the same depth of understanding of Mercurial that they need to acquire about git, before they can start to work with Mercurial without wtf's and frustration. Once you have a solid understanding of how DVCS's work, you can use both Mercurial and git without problems. But if you need to bring a bunch of beginners up to speed, somehow it goes easier with Mercurial. At least, this is my experience. If someone else has experience in training teams to start using a DVCS, and has compared both git and Mercurial, and has opposite experiences, I'd be interested to hear.

tjradcliffe 12y ago
I have had the same experience as you. I used git for a couple of years and definitely had regular wtf moments. Switched to Mercurial and they just went away. The complexity and counter-intuitive (to me, at least) nature of git's model was a major barrier to entry. I still use git now and then because github is so popular, but for a small team on a moderate-sized project I really prefer Mercurial for its ease of use.
Touche 12y ago
I simply don't agree with this. There's nothing wtf about git add, git commit, git push. Those are the commands that normal developers use. Maybe git reflog has issues but 90% of people are never going to come across them.
- worklogin 12y ago
  Nothing about that deals with collaboration. fetch/merge/pull/remotes can be pretty confusing without really wrapping your head around it.
  - Touche 12y ago
    What is wtf about git pull? > git pull origin master (fix conflicts) > git commit That's it.
    - dfabulich 12y ago
      1) Pull creates a merge commit. Why? 2) What's a fast forward? 3) What's a tracking branch?
      - somebehemoth 12y ago
        1) So you can revert the merge very easily. 2) Merging without a commit. 3) A branch on a remote server that you have a copy of locally and you want to keep track of the status of remote against the local copy (who's behind and who is ahead?). This is my basic understanding in terms of how I use git. I like Mercurial too and don't have a horse in this race.
        mpdehaan2 12y ago
        While this somewhat underscores some complexity in git, here's something I wrote trying to explain to others why and how to avoid those merge commits: http://michaeldehaan.net/post/116465000577/understanding-when-to-use-git-rebase http://michaeldehaan.net/post/116465000577/understanding-whe...
DigitalJack 12y ago
I use git every day, all day at work. It is absolutely integral to my workflow, and the only thing I know about its internals comes from people posting about them here. Needing to know anything about git's internals to be able to use git is FUD.
chralieboy 12y ago
Git Immersion (http://gitimmersion.com/ http://gitimmersion.com/) is great for getting up to speed as a beginner.

gecko 12y ago

It has greater extensibility (both in protocol and the code itself), which is why Facebook and Google are looking at it in the first place: it's possible to hook into it in such a way that you can make it scale to ridiculous sizes (see e.g. https://bitbucket.org/facebook/remotefilelog https://bitbucket.org/facebook/remotefilelog) cleanly, in a fully backwards-compatible way, without forking the product. So it's worth looking at for at least that reason alone. Beyond that, though, the team itself is leveraging that extensibility to continue to evolve Mercurial in new directions. Years ago, I was able to ship a third-party largefiles extension that worked similar to the GitHub external files thing launched a few weeks ago, and was able to get it integrated into Mercurial easily, where it was heavily used for years by people in the games industry. The team took "bookmarks" (Git-style branches) under its wing when they proved valuable, and have now added a ton of behavior to improve bookmark workflows. They can even add huge new features. the big one that Git lacks is changeset evolution. Evolution allows you to get all of the benefits of rebasing and squashing, and all the benefits of a traditional DVCS merge-based workflow. Specifically, you can see all the previous versions of a given changeset, but those versions don't need to clutter up the history unless you're specifically interested. This means you're dramatically less likely to lose critical forensics information over the course of developing a new feature, and much more likely to be able to sanely see where, over the course of several rebases, you mucked up how a chunk of code actually worked.

glandium 12y ago
> it's possible to hook into it in such a way that you can make it scale to ridiculous sizes (see e.g. https://bitbucket.org/facebook/remotefilelog https://bitbucket.org/facebook/remotefilelog) cleanly, in a fully backwards-compatible way, without forking the product. That's not entirely true. For instance, some of the scaling is going to require a new manifest format that is not going to be backwards compatible.

jordigh 12y ago

Oh, boy, I'll try to answer, and perhaps later turn this into a FAQ for our wiki: * revsets -- feature-rich DSL for querying your history, my presentation on them: https://www.youtube.com/watch?feature=player_embedded&v=NSLvERZQSok#t=973 https://www.youtube.com/watch?feature=player_embedded&v=NSLv... * templates -- the output of just about any hg command can be customised: http://mercurial.selenic.com/wiki/GenericTemplatingPlan http://mercurial.selenic.com/wiki/GenericTemplatingPlan http://jordi.inversethought.com/blog/customising-mercurial-like-a-pro/ http://jordi.inversethought.com/blog/customising-mercurial-l... * Evolve -- safely rewrite commits as a team, a safe replacement for `git push --force`: https://www.youtube.com/watch?v=4OlDm3akbqg https://www.youtube.com/watch?v=4OlDm3akbqg * Very easy to write extensions: http://mercurial.selenic.com/wiki/UsingExtensions http://mercurial.selenic.com/wiki/UsingExtensions * Mercurial scales well to gigantic monolithic repos: https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc... That's all I can think of for now.

twic 12y ago
Oh god, revsets. When i was able to use Mercurial (via hgsubversion and hg-git), i used revsets constantly, to ferret out all sorts of useful knowledge from the repository. My Git-using colleagues thought i was some kind of wizard. I switched jobs, and now i just use Git. I miss revsets so much.
gnuvince 12y ago
In that lightning talk, were you actually typing or were you playing an accelerated recording of you typing previously? Cause it seems like you type at something like 300 wpm or something insane like that!
- jordigh 12y ago
  Everyone always asks me that. It's a hack that someone else later turned into: http://doitlive.readthedocs.org/en/latest/ http://doitlive.readthedocs.org/en/latest/ I hope you were able to pay attention to the talk instead of the gimmick.

ngoldbaum 12y ago

One short answer: changeset phases and evolution http://mercurial.selenic.com/wiki/Phases http://mercurial.selenic.com/wiki/Phases http://mercurial.selenic.com/wiki/ChangesetEvolution http://mercurial.selenic.com/wiki/ChangesetEvolution The latter is embodied in the Evolve extension, which I use for day-to-day stuff and find incredibly useful. http://mercurial.selenic.com/wiki/EvolveExtension http://mercurial.selenic.com/wiki/EvolveExtension The reason Google and Facebook are interested in mercurial is based on the remotefilelog extension: http://mercurial.selenic.com/wiki/ScaleMercurial http://mercurial.selenic.com/wiki/ScaleMercurial https://bitbucket.org/facebook/remotefilelog https://bitbucket.org/facebook/remotefilelog https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc... Performance on huge monolithic repositories like the ones Facebook, Google, and Mozilla work with is actively considered by the mercurial developers when integrating new features.

kyrra 12y ago

To add to the Google bit, from Facebook's F8 there was this interesting tidbit (source[0]): > Quote from Google: "We're excited about the work Facebook is doing with Mercurial and glad to be collaborating with Facebook on Mercurial development." (Well, I guess the cat is finally out of the bag: Google is working on Mercurial. This was kind of an open secret for months. But I guess now it is official.) As well, if you search the Mercurial-devel mailing list[1], you'll see that Google engineers has been committing to Mercurial for a bit now. (Looks like they started in Aug 2014, and really picked up in Nov 2014). [0] http://gregoryszorc.com/blog/2015/03/28/notes-from-facebook%27s-developer-infrastructure-at-scale-f8-talk/ http://gregoryszorc.com/blog/2015/03/28/notes-from-facebook%... [1] http://mercurial.markmail.org/search/?q=list%3Acom.selenic.mercurial-devel+%40google.com http://mercurial.markmail.org/search/?q=list%3Acom.selenic.m...

rifung 12y ago

I heard that Facebook picked Mercurial because it was easier for them to make it work at their scale. On the other hand, the company I currently work for also uses Mercurial, but all the developers besides maybe the founder (I haven't asked) prefer Git. I don't know the specifics about why everyone feels that way but from what I gather it has to do with branching being easier.

jurip 12y ago
I've come to the conclusion that git got branches right. The idea of permanent metadata for branches is appealing, but repository-wide single namespace is bit of a PITA in some circumstance. Mercurial's bookmarks are the same as git's branches, but Bitbucket support is lacking. The other big thing git has is startup speed. Python is slow. Something like chg helps, but it's a workaround.
- ArneBab 12y ago
  I only see startup problems with hg when on the university cluster, where the filesystem is slow when accessing many files (metadata access). Startup speed for hg is on my machine below 100ms, less than the time most people need to type a single letter.
- rbehrends 12y ago
  I am not really happy with either Git's or Mercurial's solution. Git's branches introduce too much fragility in the system for end user consumption (because branches are responsible for both naming and keeping commits alive) and do not allow you to describe sets of commits (nor is there an alternative feature for that), Mercurial's branches are too permanent in that they cannot even be renamed (well, there's an extension for that, but that's not without issues). Mercurial bookmarks still do not allow you to label sets of commits, but at least aren't responsible for the liveness of a commit. In practice, I like both Fossil's and Bazaar's model better.
  - Skinney 12y ago
    What do you mean by a "set of commits". Why not just have topic branches? Branches isn't the only thing that keeps commits alive, you also got the reflog and tags. I have a hard time understanding why you would want to keep something alive that isn't reachable from the history.

rbehrends 12y ago

> What does Mercurial have over Git today? Aside from what others have mentioned, the biggest thing for me personally is hg share, i.e. the ability to have two or more independent checkouts of the same repository. Git does not really support this. Your options are (1) git-new-workdir, which is not safe and can lose data and (2) doing a complete clone, which is cumbersome, because you can't directly diff/merge against branches in the other repository, but have to push/fetch first. Disclaimer: I'm one of the strange people who (by preference) still uses Bazaar over Git and Mercurial whenever possible, so that may skew my preferences.

wwb099 12y ago

TortoiseHG. SourceTree is getting to be OK, at least on windows but git gui apps suck. And if you are doing anything non-trivial and non-automated then gui SCM clients are just fine kids.

Too 12y ago

> What does Mercurial have over Git today? Not related to the core product but still very important for the experience: A decent Windows gui, tortiose hg. I have tried all the guis for git, both commercial and free, and they all suck rats ass. Either they are slow, they only support github, they look like shit, they only support the most basic commit operations, they can't show the diff between selected revisions, they destroy your merges and simply make everything related to source control a pita. There are many many of them available that can do some of the things I listed above but none that does all of it.