Mercurial vs Git: Why Mercurial?

http://blogs.atlassian.com/2012/02/mercurial-vs-git-why-mercurial/

by LeafStorm • 14 years ago

95 84 14 years ago

blogs.atlassian.com

aninteger2• 14 years ago

Regarding the "A Sane Command Line Interface" topic. Linus mentioned in his talk at Google about Git that he often chose the opposite approach to do things rather than follow the Subversion approach. This might be why the commands are not named the same as Subversion commands.

git add/rm handles making changes to the index and there is no similar concept in mercurial or subversion.

Argorak2• 14 years ago

I think this is not only about similarity. For example, branching works with `git branch foo`, but it doesn't immediately switch to that branch. If you want to do this, `git checkout -b foo` is the way to go. While this might make some sense if you understand the details behind git, it is horrible from a user interface perspective. I know a lot of people that didn't know about checkout -b because they never thought about looking there.

Also, some features are half-implemented, for example `git add -p` which does not trigger on file-additions (and sometimes is broke out of the box on some distros).

I like git, but the interface: not so much. Too many rough edges.

The blog post does not illustrate this, though :/.

Update: and for the downvotes, would you care to explain why?

weaksauce2• 14 years ago

I'm not downvoting you but the git branch command is orthogonal to checking out a branch. The branch command adds, removes and lists branches. The checkout command switches between them. There is a convenience command that does a checkout and create. The main thrust of the checkout command is to change branches so if a branch does not exist they give you a convenience method to do so.

edit: git add -p(atch) is supposed to create patches of existing files assuming that that is the most common use case. Use --interactive if you want to add new files and still do interactive patching.

jacknagel• 14 years ago

You might find `git add -N` ("--intent-to-add") useful. It's an extra step, yes, but it allows you to e.g. view the content of new files with `git diff` without actually staging the content for commit, and will allow you to stage that file during `git add -p`.

benatkin2• 14 years ago

I like what's on the git part of the table better, and it isn't just familiarity with git but familiarity with unix. I'm glad that since I use git and git-svn, I don't have to type remove and move instead of rm and mv.

LeafStorm2• 14 years ago

One thing the article misses is that hg also has a bunch of built-in aliases for a lot of these commands, including:

* mv for move

* rm for remove

* co for clone (which SVN uses as an abbreviation for svn checkout)

* ci for commit

As well as the fact that you can abbreviate any command that hg doesn't have specific aliases defined for by typing any unambiguous prefix. Git, on the other hand, has no aliases by default, and no prefix aliases.

julian37• 14 years ago

Come on, those are very minor quibbles.

If you want aliases, it's literally a matter of five minutes to find some (e.g. [1] is the 4th hit for a google search for "git aliases") and put them into your .gitconfig.

And I would argue that prefixes are more confusing than helpful, especially in conjunction with aliases. For instance, going by prefixes you'd expect "co" to mean commit, yet in hg/svn it means clone/checkout.

[1] http://gitready.com/intermediate/2009/02/06/helpful-command-...

buff-a• 14 years ago

Gosh, I know. That's awful. Its much better that hg allows people to type hg mv, rather than forcing lazy people to modify the .bashrc file so that they can type "ga" instead of "git add".

I mean, I know "hg mv" is actually longer than "ga", but by golly, expecting unix shell users to know about the alias system built into the operating system is just the kind of elitism we can expect from linus.

badboy• 14 years ago

It is a bad thing to have just one command to move files instead of 3? Nah, I don't get it.

That git has different commands than svn is because it is different. Why should it adopt any of the commands if it does different things?

When I started with git, I never ever destroyed any of the history. Because it's not easy to do so.

I looking forward to read the follow-up article where he wants to point out some advantages of git.

NelsonMinar• 14 years ago

GitHub is the first and last reason to prefer Git to anything else. That community is so vital right now, it cements Git as the essential VCS. I could believe Mercurial is better in some ways than Git and I could even believe Atlassian's BitBucket service is in some theoretical sense better than GitHub. But most code is on GitHub, so git wins.

rsanheim• 14 years ago

This. Github is the killer app for dvcs. Both git and mercurial are good enough, and github simply makes it a no brainer.

bwarp3• 14 years ago

Apart from the large chunk of us who don't do open source stuff and manage products with it.

Github brings us no benefit then.

quicksilver032• 14 years ago

Irrespective of git vs. hg, there is one case where BitBucket is definitely better than GitHub: when you have many repositories and a variable number of contributors.

My company is in this exact situation and we've chosen BitBucket because the pricing model per contributor is a much better fit than GitHub's model for our usage pattern.

iwejfweoifjweif• 14 years ago

I haven't looked at the pricing for BitBucket but it seems (in my experience) you can have as many contributors as you want in an "organization" on GitHub and you only pay based on the number of private repos that organization has and forks of those repos don't count.

Is that not your experience?

rogerbinns3• 14 years ago

Show me how you set priorities on tickets at Github? Apparently they are philosophically opposed to you being able to sort issues by importance.

One thing I love about Google Code is that they allow multiple repositories per "project". This is very important for when you want to share the same issue tracker, wiki, downloads etc because the items are related. Many of the overall projects I work on have a server piece, some tools and an Android client. They all work together as a whole. When there is an issue, it is often not apparent where the blame actually lies and which component will need to be changed to fix it. (Eg a font being too large in the Android client could have been generated from the server which served up templates made by a tool.) Google rule out private hosting so they can't be used in this scenario - http://code.google.com/p/support/issues/detail?id=1829

As a regular user of Google Code, Bitbucket and Github, the arbitrary differences are very annoying. Each uses a different wiki syntax, and most relevant each has a different syntax for closing tickets in a commit comment - they are similar but not exactly the same.

tednaleid2• 14 years ago

We use tags on github for priority. Combined with milestones, we're easily able to figure out what to work on next.

Right now just limited to "High", "Medium" and "Low", but we could have whatever level of granularity we want. We can also color code the tags (red = high, orange = medium, yellow = low).

The thing I really miss on github is a place to stick a numeric estimate for how long something will take to help with knowing how much capacity we have left in a release/iteration.

jamesgeck0• 14 years ago

Github Issues isn't their strongest point. One sticky bit is that it doesn't seem to keep track of the full history of a ticket.

tomjen3• 14 years ago

I don't see the number of programs on GitHub mattering at all. It is not like you can't use a gem from github and two from bitbucket and one from savannah and one from an old floppy disk and two you were emailed a tarball.

Github is no doubt useful, but don't ignore the others -- this is not facebook.

wyck• 14 years ago

I disagree, we use mercurial because it has a full product line of management tools, the issue tracker is 1000% better with mercurial compared to github. I don;t care where "most code" is, I care about where my code and me teams code is.

philbo• 14 years ago

The point, imho, is not about you caring where your code is, it's about other people discovering that's where it is too.

jonstjohn• 14 years ago

I love Github and its community, but it absolutely is not the first and last reason for my team to use Git. Our code is highly proprietary and Github is not the solution for us. I continue to use Github and agree about its vitality, but it isn't a one-size fit all for teams.

StavrosK2• 14 years ago

There are 6 responses your comment and not one has mentioned that both hg and bzr have full interoperability with git. I use github extensively with both bzr and hg, and haven't used git in a while. Your personal choice of SCM is entirely irrelevant to which web service you use.

fryguy• 14 years ago

As a lover of bazaar, how did you manage to do that? I always feel so dirty when I have to use git because everyone uses github.

statictype3• 14 years ago

Can you tell me how you use hg with github? I really prefer working with mercurial but have often switched to git for projects I want to put on github. I know there's some git plugin for mercurial but I thought that was old and unmaintained?

acdha3• 14 years ago

The part which struck me: "For the times when you do need to rewrite history in Mercurial, you can turn to extensions like collapse, histedit and MQ. Keeping this functionality out of core prevents new users from accidentally using it until they’re ready."

What this means in practice: when you need to rebase in Git, you simply do so. When you need to rebase in Mercurial, you have to enable a bunch of extensions which aren't well polished or documented because they're not part of the standard feature set and many people have been discouraged from using them. That second situation is far more likely to cause data loss, which is a pity because rewriting local history is a valid operation which often produces cleaner commits and avoids merge failures.

I started using Mercurial earlier than Git but have been using both for years. Mercurial remains the only one where I have experienced data-loss (histedit) and the one where I had to switch to a less natural workflow to deal with limitations of the tool (e.g. patch queues are such a kludge-fest it's obvious that nobody really believes you should use this feature).

kisielk• 14 years ago

To be fair, the MQ and rebase extensions are shipped with mercurial, just not enabled by default. They share the same bug tracker as the main project and in my experience are just as well documented and tested as other bits of Mercurial.

It's also been my experience that non-expert users don't understand the repository DAG model well enough to perform history rewriting reliably and without error, which I think is one reason these features are disabled by default.

Finally, as of Mercurial 2.1 they now have the concept of "phases" of commits which make local non-shared commits mutable whereas commits which have already been shared are immutable. This new feature is a first step to safer history editing operations becoming more mainstream mercurial commands.

guard-of-terra4• 14 years ago

Why should I have to assemble my DVCS from parts before I would be able to use it? If I wanted Lego I would have got one.

Shelf isn't shipped with mercurial and it's really really painful without it: you make some changes to some wrong branch and now you need either shelf or major pain with rebase.

If non-expert users don't understand enough to do rebase, they're screwed: they better go cry in a corner since you can't solve any non-trivial scenarios without rebase and you're going to run into those all the time.

Not that I like git, but still. And since Eclipse plugin for SVN merges much better than both git and hg, I often wonder why do we bother at all :(

acdha3• 14 years ago

I'm aware that they're shipped but disabled by default. I think there's something of mental blind-spot, however, because they're discouraged or treated as something only experts should use: I've never seen anything like the level of obscure error messages or cumbersome UI in any part of Mercurial which is enabled by default. I think it deserves more respect as a valid working style.

I would disagree with the statement regarding history rewriting and non-expert users, to note two exceptions: Git's amend commits are extremely easy to explain and rebase is not that much harder for common cases. These same users are going to have issues with merges and rely on good tool support nearly as much in that situation, too.

What I think would be welcome in Git is the very nice phased commit feature you mentioned. That's a great example of where the concern should have been directed towards the UI rather than the operation.

rogerbinns3• 14 years ago

I've also been using Git and Mercurial for years. Git is the only one where I have experienced data loss, not to mention obtuse error messages that I could only end up fixing by doing a reset.

Under the hood the two systems are very close. What differs is the interface, defaults and "taste". I think the Mercurial ones are a closer match for perpetual intermediates and smaller projects/teams while Git's choices are a closer match for expert users and larger teams/projects.

Use the best tool for the job and that closest matches the work being done and the team at hand. There is not one perfect answer.

j-kidd2• 14 years ago

Best tool for the job, can't agree more with that. We have a team that insists on using git when:

- it is just a small team (less than 5 devs)

- there is no github, just a locally hosted gitorious instance (proprietary project)

- the lead dev who picks git is using Windows half the time

- there are less technical people who need commit rights (e.g. changing reports layout, changing CSS, etc)

I believe the "git already won" mentality (which is very apparent in the comments of both OP article and HN) get these people to pick git over mercurial. And once they become familiar with git, they won't let go, due to the sunk cost of learning gitology[1].

[1] http://jordi.inversethought.com/blog/on-gitology/

pnathan2• 14 years ago

I've found it distressingly easy to kill changesets in Git unintentionally.

That does not make me a happy camper. I use Git because of Github - GH is a very nice system. Hg IMO is a better interface if you just need to pick it up, hit it a few times, and then go do your thing.

fr0sty• 14 years ago

> I've found it distressingly easy to kill changesets in Git unintentionally.

Mind if I ask how you manage to easily kill changesets in a 'distressingly easy' manner?

In my experience it is somewhat difficult inadvertently lose commits (especially to lose them for good) unless you go out of your way to do so.

azakai• 14 years ago

> (e.g. patch queues are such a kludge-fest it's obvious that nobody really believes you should use this feature)

No, plenty of people like patch queues, including me. They are very good at what they do.

I prefer git overall, but let's not bash competing projects with huge overgeneralizations like "nobody really believes you should use [patch queues]".

acdha3• 14 years ago

It's a little bit of an overgeneralization but it's a feature which is disabled by default and generally described with caveats like for experts only, in certain situations, etc. while it's such a routine way of life for Git users. I really do believe that's the sign that the Mercurial community is a lot less comfortable with that working style in general and that impression has been supported by the general clunkiness and obscure failures which is completely unlike the normal Mercurial experience, suggesting patch queues are an under-loved feature.

I am happy to see phased commits - perhaps that'll start leading to a little more UI support for operations which historically were considered edgy.

nessus42• 14 years ago

I use both Git and Mercurial and I love Git, but I think that Mercurial is far better for the typical environment, where it's already virtually impossible to convince people that they should switch from Subversion to something decent.

I think that most programmers will learn a little Git and then run away fleeing in terror and become all the more entrenched in their woeful belief that Subversion is adequate. In this sense, I think that Git is doing more harm than good. If the current buzz were for Mercurial, which is far more approachable than Git, I think that most Subversion users might try Mercurial out, think, "Hey, this is pretty nice!" and then be perfectly happy to switch. Git, on the other hand, offers all the power that anyone could ever need, but even I, who am pretty fluent with Git, often have no clue what other Git users are talking about when they explain how to do something. I never have that issue with Mercurial.

Also, I've never had any problem with histedit. Though hgsubversion has definitely caused me to get a few extra gray hairs from time to time.

jcoder2• 14 years ago

"Backwards Compatibility

The maintainer (and original author) of Mercurial, Matt Mackall, is a strong proponent of backwards compatibility, which is important when you’re choosing a version control system that you plan to rely on for a long time."

Well, that's air-tight. You sold me.

outworlder• 14 years ago

And since when GIT ever broke backwards compatibility?

almost never. Details below:

http://stackoverflow.com/questions/1314668/git-repository-ba...

aninteger2• 14 years ago

I'm pretty sure jcoder was being sarcastic :).

tsewlliw• 14 years ago

Fwiw, fossil is engineered from the ground up to have an enduring disk representation if that's the top of your list.

falcolas• 14 years ago

I find the "Easy to Extend" argument very unconvincing.

The example shell script is not at all integrated with hg (no more so than any other Unix command), and these are not Windows portable, as the article indicates is so very important. Git appears to have an edge here, since you can integrate shell scripts directly into the git interface.

Git allows aliasing just as easily as hg.

luser001• 14 years ago

I did 'git log' on a repo with 60K commits and about 3k files. I finished in a second or so.

I imported that git repo into Mercurial and did 'hg log'. It took 13 sec.

This was about 3 years ago. I haven't looked at Mercurial again. Maybe things have changed now?

sdfjkl• 14 years ago

I used to worry about Git vs. Mercurial too. Neither made me really happy. Then I found Fossil[1]. Now I am coding instead of worrying about version control.

[1] http://fossil-scm.org

wladimir• 14 years ago

I eventually settled on git, for no particular reason but to choose one. They are equivalent for all practical purposes, but require learning different commands to do the same thing. It was taking too much mental bandwidth for me to context-switch between them.

It's great to see some diversity though.

Edit: There are also plenty of scripts to convert between repositories of one format to another, and communicate between them, another reason to use the one you're comfortable with...

tednaleid2• 14 years ago

Almost all git vs mercurial differences for most users are cosmetic/usability/culture related. With a few extensions turned on, you can use either interchangably. The biggest exception to this is if you use named branches (a fairly common thing in git, slightly less so in mercurial). Mercurial hard codes a branch name in the metadata of a commit, git doesn't do that. I prefer git's method as it means that a commit can move around on branches (or really that branches can point to different commits) without messing with the commits themselves.

elehack• 14 years ago

Branching is one of the big differences. I find Mercurial's named branches mostly useless; fortunately, with some care, bookmarks can be used to simulate Git-style branches.

I think, early on, the Mercurial community favored cloning as the means of creating feature branches, while Git used named branches to do so. But in many cases you want to be able to switch lines of development in a single repository (especially when using a workspace-based IDE like Eclipse), so the Git model becomes a win.

codesuela• 14 years ago

>Many programmers prefer to use a graphical interface to their version control system instead of working through a command line.

to be honest git is my first true VCS (because I was used to working on my own and my VCS was Wuala sync that synced every changed document to the cloud + daily backups to another HDD). I have used the built in revision control system in Visual Studio but not extensively. When I started out with git I was looking for a GUI client because I assumed that it would be easier to use but now I much prefer the cli version of git and I assume this is true for most Linux (and possibly Mac users idk). I would even go as far as to assume that this is true for most HN readers. Anyone care to comment?

Also git (even direct publishing to github) is built into PyCharm/RubyMine and there is also TortoiseGit for Windows (not sure about other OSs)

edit: I just realized this might be slightly OT but I still hope this wont be downvoted into oblivion as I'd love to hear some opinions

wonderzombie2• 14 years ago

For my part, I started using git at the command line because most of the Linux GUIs were pretty weak. They may have gotten better since I looked (1 yr?) but at this point I'm comfortable with the command line interface.

Also, I jump between Linux at work and OS X at home, and the git workflow is the same on either if I am using the command line.

The Mac GitHub app seems really nice, though.

cageface• 14 years ago

Or, let's be honest, because Github already nailed Git so we had to base bitbucket on something else.

jcapote• 14 years ago

The need to be a technology contrarian, that's why.

postfuturist• 14 years ago

Why would their product marketing manager be bashing Git with accusations like Windows support is a "completely separate project" when it's the first download link on git-scm.com?

This is a very thoughtless article full of issues of personal taste and FUD towards Git. I was starting to really like Atlassian since they added free private Git repos on bitbucket.org. We've been considering using JIRA and other paid services from them where I work, but this gives me serious pause.

frio• 14 years ago

Not that I'm biased here (I use git and am more than happy on it), but git on Windows is an abomination as compared to Mercurial. Other than the sometimes complex commandline statements, it's one of git's bigger problems.

mappu• 14 years ago

I tried to git diff the other day. msysgit screams that //its own bundled terminal// "is not fully functional" and dies.

Yes, there's a workaround[1], but i'm sticking to Hg at work and at home for now.

____________

1. http://stackoverflow.com/questions/7949956/git-diff-not-work...

jandy• 14 years ago

An "abomination", really?

I use Git regularly--and happily--on Windows with very few issues. It is considerably slower than its Mac/Linux builds, but aside from that the experience has been positive.

What exactly do you consider to be Git's failings on Windows? And how is Mercurial superior in those respects?

BerislavLopac• 14 years ago

I have recently switched from Windows to Ubuntu full-time, and one of the few programs I'm sorely missing is TortoiseGit. Just like its hg counterpart, it made working with git a pleasure, and it took a while to adapt to the command-only style of work.

LeafStorm2• 14 years ago

The fact that the average HN'er seems to be completely unwilling to even consider using a tool different than git is rather depressing. While I understand that git does have some impressive features that Mercurial does not, most of them are somewhat esoteric, and I certainly doubt that they are enough of a motivation to justify this viewpoint that git has already won and that Mercurial is a pile of trash.

"The more I use git, the more I realize that everyone enamored with it has a severe case of Stockholm syndrome." -- Matt Might [1]

[1] https://twitter.com/#!/mattmight/status/161495662033248256

wowzer• 14 years ago

Having used both git and hg in my own projects, I have strong feelings towards both, although in the end they're like siblings who got the same lessons from their parents and just choose to go to different colleges.

With that said, I'm not sure this post really pushes one to use hg. The comments about being close to svn are pretty lame. While I get the point; subtle differences really won't matter after the first week. And getting over the mental difference that comes with distributed version control is a lot more to take in than a couple letter changes in commands.

The two things I most like about git are how -- by default -- you can choose line-by-line what gets commited. Where as the default in hg is to commit all changes. This actually changes how I find myself coding and my comfort with the repo. I know you can do something similar in hg, but it's a bit of a nuisance.

The other standout is how simple branching is in git.

Mercurial vs Git: Why Mercurial?

Related Stories