I have read many good comments on lobsters about mercurial. Why do you prefer mercurial over git? What are the main features that make you use it instead of the more common git?
EDIT: How well does mecurial work with git servers? Does the hg-git bridge works properly in general? Do you use it in work? Most of my client related work is done on git and I don’t want to screw things.
Here’s an example: revsets. Oftentimes people want to search history for a set of commits matching some predicate. For example, the commits created by one author.
An easy way to satisfy this need is to add additional keyword arguments to the “log” command, which lists commits. This is largely the approach git took, and it’s kind of a mess. A huge number of keyword arguments that are difficult to compose and really only usable with the log command.
Mercurial’s approach was to step back and solve the more general problem: how do I express a description of a set of commits? The solution they ended up with is revsets. Almost every mercurial command takes a
--revor-roption, which will take a revset. This means that adding new revsets doesn’t clutter the user interface. There are a huge number of revsets and they are composable. For example, to search for all the commits authored by me I could do,hg log -r 'author(ngoldbaum)'.Just to add, templates are more of the same principle. Instead of adding a bunch of idiosyncratic flags to every command, templates are another DSL that work with anything that displays web or commit information. They also look vaguely like Jinja or Django templates, so it’s nice that they have a certain familiarity to them.
hg commit does what I want.
More particularly, if I’m already familiar with cvs up and cvs commit, mapping that to hg pull and up and hg commit and push is conceptually similar. The documentation talks about the things I’m interested in, commits and changes, not graphs of objects.
I used SVN briefly from a GUI client before going full on git. That’s to say, I don’t have experience with other change control systems.
Can you explain what’s different between git and hg with those commands? Git has the same ones.
Git has a concept of a staging area, which is unique to git. A lot of people have come to like the stating area, but people coming from other VCS tools find it weird.
If you miss the staging area coming to hg from git, you might find
hg commit -ito be useful. There’s also a curses interface for the interactive hunk selector that is really nice, which you can activate withui.interface.chunkselector = cursesIt’s not always easy to quantify the difference. But as one for instance: hg commit commits the modified files. I don’t have to specify -a. It seems every git command requires at least one –for-realz option to make it go.
“
svn commit” is the same as “git commit -a && git push”This is a bit of an hg FAQ. Here are some responses from a recentish time when this was asked in HN:
https://news.ycombinator.com/item?id=9467096
In short: easier to use, has some powerful features that git doesn’t have, such as revsets, templating, tortoisehg, giant semi-centralised repos, and changeset evolution
Performance wise is it fast enough to deal with code bases with 100k or more lines? I have read some comments stating that it is not very fast.
In general, yes, it’s extremely fast. 100k lines is fine. Mercurial itself is almost 100k lines (ignoring tests, which adds more), and I’d classify that as small for what hg is used for by FB and Mozilla.
The repo I work in, mozilla-central, has around 19 million lines I believe and it is very fast. I’m sure Facebook has a similar number if not more.
I work for Facebook.
Facebook’s mercurial is faster than Git would be on the same repository, but that’s largely because of tools like watchman hooking in to try to make many operations operate in O(changes), instead of O(reposize). It’s still very slow for many things, especially when updating, rebasing, and so on.
Your comment made me curious, so I ran cloc over my local copy of mozilla-central. By its count there are 18,613,213 lines of code in there at the moment; full breakdown here.
Yes. For example, facebook’s internal repository that is hundreds of gigabytes is run on hg. For really huge repositories (much, much bigger than 100k lines) you can use some of the tricks they have for making things like “hg status” very fast for such a huge repository.
Mercurial Evolution is turning out to be a bit of game changer.
I encourage you to have a closer look.
If you need to do a large scale refactoring as part of a small team that is working on a code base actively being developer by a larger team… this is just magic.
Apart from that, I have heard many folks whinging about git merges that went wrong. I suspect it maybe PEBKAK, but mercurial smooths the work flows so nicely most of the PEBKAK’s simply don’t happen.
Other than revsets which have already been mentioned, I love how customizable and extensible it is. I’m a bit of a workflow geek, and I’ve been able to customize my workflow exactly to my liking using aliases, revsets and extensions in ways that I’ve never been able to with git. It also helps that the code base is written in python and as a python developer, relatively easy for me to understand. And assuming you know python, extensions are actually quite simple to write!
I also find the default cli more intuitive and composable.
I really like the MQ extension. It’s very nice when you are developing a patch series, and (for me) is a lot less nerve-wracking than Git, because it’s just a bunch of patches in a folder and a file listing the order.
Even then I like Git a little more :) And it looks like the Mercurial authors really dislike MQ.
MQ has been largely supplanted by the evolve extension. With evolve it’s trivial to edit commits in a series and then automatically update the series to reflect a change in an early changeset. Evolve is nicer than MQ largely because you only need to learn what a commit is rather than also needing to learn what a patch is (basically a pseudo-commit) and all the extra commands MQ provides for manipulating patches. You might be interested in this section of the evolve docs: http://www.gerg.ca/evolve/from-mq.html
How well does mecurial work with git servers? Does the hg-git bridge works properly in general? Do you use it in work? Most of my client related work is done on git and I don’t want to screw things.
I know some people use hg-git, but how well it works depends heavily on your code review workflow. It gets kind of thorny around the edges when you want to edit history.
I’ve been tinkering with other ideas to try and make it more pleasant, but nothing real has materialized.
I feel like the opposite question is equally valid. Why do you use git over mercurial?
Here’s my perspective. I think the adoption of git skyrocketed with github. I know that some hardcore devs have been using an SCM for a while, but the average web dev was largely just copying files locally and uploading files up to their servers via FTP. SVN was around and I had used it a bit, but branches were a pain, and I remember the tooling wasn’t great at the time either. When github came along and was a really slick collaboration platform that happened to use git exclusively, all of my peers just picked up git because github was so good.
I never have used mercurial, but I think regardless of the benefits of mercurial, it just didn’t have a shot at the same popularity because there wasn’t a platform that really changed the way people collaborate like github. I would guess that if a platform like github was built around mercurial at the same time, it may have had the same level of adoption.
I know that the github folks were really into the benefits of git at the time, but I believe the magic was in the platform not the SCM.
Long answer short, I don’t use mercurial because none of the companies I have worked for ever have, and on my personal stuff I just use git because I know it.
That’s one of the most interesting points about the popularity of git - it’s used by many people who would never have thought of using an SCM before, from web developers to ops people. Even stranger, to me, is that for all its power git has a worse UX than what was there before - CVS, Subversion, even RCS, are all relatively quick to learn and easy to use. git isn’t either of those (and I say that someone who likes it, for certain values of “like”), yet it’s seen huge adoption. This is due in no small part to Github, for sure.
IMHO, the influence of git on software development cannot be understated - I think it’s made SCM something every developer needs to know and master, rather than a set of niche concepts. And that’s a Good Thing.
It probably also helped that some of the people involved early on with Github promoted Git heavily, going to such lengths as the “why Git is better than X” stuff and the actual git-scm.com website. Previously, you had to go to some part of the Linux kernel website to learn more about Git.
I don’t. Mercurial is so tiny compared to git that it needs justification. You don’t need to justify git, since it’s just the default. Everyone uses git, there’s tons of things built on top of git, and git is just the way things are. There’s no reason to convince anyone to use git instead of using hg, since they are way, way more likely to already be using git instead of hg.
It’s not like we have to tell GNU/Linux users that they really should be using Windows/macOS or tell BSD users that GNU/Linux is what they really should be using. The minority users are almost certainly already aware of the advantages of the majority software but decided to stay with the minority software regardless. It’s only the other direction that really requires a defense.
I think you always need to justify the default. If you can’t justify the default then you’re literally just cargo culting without actually evaluating the tool or its alternatives.
But following that argument, there are almost certainly people who use mercurial because it’s the default where they work, and where they first worked, and have never felt the need to use git, or tried it and didn’t like it because it was mildly different from what their default was.
Is this the default mode of thought around here? New to the site, just curious.
I just meant to say, the Glory of Git is a very well-known song. Give us a chance to sing the Harmony of Hg.
Sure, you have a point. In my case I use git because most other people I have worked with use git. jordiGH said a few months ago that “the userbase is dwindling, but the development, if anything, is speeding up”, so being proficient with git is a must for me since I am a freelancer. I need to know how to use tools my clients use, even if I don’t love them.
In 2006 or 2007 I moved from SVN to mercurial and I really liked it. However, almost no client or job I could find used mercurial, so I had to learn git. In addition to that, the boom of github made me stay comfortable with git. Nowadays, being picky about tools I am checking if other devs that have a similar mindset to mine are using mercurial instead of git.
The fact that git checkout <folder> and git checkout <branch> overlap is a pretty extreme example of nonsense with git.
I’d be very interested in seeing a similarly bungled API decision in hg. hg has always given me a better feeling for this reason, and I don’t really get to use hg that much.
There’s a couple of embarrassing quirks in hg’s interface.
Every command that takes revision numbers (commit hashes, bookmarks, tags, branch names, revsets; all are equally valid arguments) as an argument, takes it as
--revwhich can be shortened to-r… except forhg statusfor which-rexpands to--removed, which shows you only removed files. You have to use the long--revforhg status. Due to backwards compatibility, this can never be changed.Another emabarrassment is copying commits around from one part of the DAG to another. Canonically, this is supposed to be the
hg graftcommand which replaces the deprecatedhg transplantcommand. However,hg rebasealso has a--keep(original commits) option that accomplishes copying, and the options forhg rebaseare different than forhg graft, e.g. different flexibility in modifying authors, commit dates, branch names, or folding the result into a single commit. I would like to enrichhg graft’s feature set and deprecatehg rebase --keep. In Mercurial, deprecation just means that the feature is not exposed in the default help text, but it will never be removed.