Hacker News Reader

Comment by imakesnowflakes | Hacker News Reader

Mercurial user for the past 6 or 7 years here. I cling to Mercurial despite people asking me to move some of my side projects (nothing substantial though) to git and github.

I refuse to do that out of principle. I think Mercurial should have taken the place of git as the widely used DVCS. And I try to be THAT change I want to see.

That being said, It would be great if someone can get the hg-git plugin to work seamlessly with newer versions of Mercurial on Windows and Linux, so that I can keep using Mercurial even if a project I am involved in uses git.

View on HN

I was really surprised that Git "won" because I thought that Mercurial's friendlier CLI and being written in Python would give it an advantage. I think I underestimated how good it makes people feel to understand something incredibly complicated. I guess immutable history was a turn off for many people as well.

This fake interview is pretty funny:

"Linus: Git has taken over where Linux left off separating the geeks into know-nothings and know-it-alls. I didn’t really expect anyone to use it because it’s so hard to use, but that turns out to be its big appeal. No technology can ever be too arcane or complicated for the black t-shirt crowd."

http://typicalprogrammer.com/linus-torvalds-goes-off-on-linu...

The main thing I found was that Mercurial was only easier for the simplest introductory tasks, where Git has largely compensated with tons of documentation, tutorials and, later, improved command-line UI. Once you needed to do anything more complicated (e.g. working on against an upstream repo you don't have commit access to) you tended to quickly end up in documentation lacunae and semi-supported extensions which rotated in and out of favor depending on which year the guide you'd found was written.

My team started using Mercurial a couple years before Git but eventually migrated over because in practice Git was less surprising and nobody had lost data using it.

That is a clever fake interview quote, but the whole notion that hg's "easier" interface should have made it won misses the point. hg's interface is more familiar (especially since we were mostly all coming from subversion at the time). Git won because it's workflow is so much better than mercurial's. Light-weight branches are better than hg branches (I know they have bookmarks now but I don't recall if they had them back then). The index is a fantastic idea that makes writing clean commits easy (I think the comparable hg option at the time was mercurial queues which are much more cumbersome to work with imo). Rebase is functionality that hg didn't include out of the box. Being able to edit commits in git is something I greatly appreciate for fixing typos and stuff.

tl;dr: the interface of mercurial may be more straightforward, but git won because it allowed people to work better.

You're right that Mercurial didn't have bookmarks until years after Git had branches. There were various things you could do to get a similar effect (eg having a branch with multiple heads), but none quite as good, and it took the Mercurial team a long time to come around to the idea.

I have to disagree about the index, though. I use Git every day, and i'm still struck by how pointless the index and the idea of staging is.

Ditto rebase. The routine use of rebase still seems completely wrongheaded to me. Mercurial's convention of preferring merges is better, and the last few years' developments around safe evolution of history really show rebase up as the misconceived hack it is.

Mercurial got 'commit --amend' a long time ago, but even before that, it had 'rollback', which undoes the last commit, leaving the working tree untouched (that is, with the state it had in the commit), so you can make your fixes and commit again.

I'd entertain the argument that Git won because it was better if even a handful of the people who now use Git had learned both Git and Mercurial and made an informed choice between them. That simply does not appear to be the case. Git got ahead because Linus invented it, and won because of GitHub.

Nice comment. One gripe: "rollback" undoes the last transaction, which isn't necessarily the same as a commit. It's deprecated now for that reason.

> I use Git every day, and i'm still struck by how pointless the index and the idea of staging is.

This is probably more a symptom of the fact that either your workflow doesn't require an index or you don't understand its value.

Either way, the index is by far git's more popular and used feature, besides branches.

Care to elaborate?

I use Git on a daily basis, but I never understood it.

If I just want to commit a specific part of my changes, I just do it. It's nice to see which files are staged for a commit, but I also see them in the commit msg comments.

What if the same file has 2 separate commits you want to split up?

I just noticed recently that TortoiseHG lets you do that in the GUI. Definitely is a nice feature. I only just started using Git and did like the ability to cherry pick from a file, but happy to know I can still do that with hg.

Actually Hg record can do this. It lets you 'edit' a hunk using a text editor, before adding it to the list of changes to include in the current commit....

Yes, this is a very underhyped feature.

They're called "hunks" in git parlance: sections of the file that define a "diff". A diff on a file can be made of multiple hunks.

Very often, my changes to a file are a mix of "fixing a serious bug" and "minor refactoring" and "removing dead code". When the time to commit comes, git makes it trivial to separate all these changes in different commits so that each commit does one thing and one thing only.

You can use "hg commit -i". This is a new feature in hg 3.4, but in older versions you can turn on the record extension.

staging is wonderful. I'm sure hg must have something similar.

I can't tell you how many times I've shot myself in the foot accidentally committing stuff to svn when I just meant a single file.

I don't use hg much these days but you can just pass the file(s) you want to commit to 'hg commit'; no need for staging. Even better, hg (or its shell integration at any rate) has tab completion so it's easy to go though the modified files and pick those you wanted to commit. I kinda miss this now I'm working with git mostly.

Do you know about commit --amend? Seems like having both is redundant.

I use Git every day, and i'm still struck by how pointless the index and the idea of staging is.

I find it amazingly useful. The staging area is for building your commit. I always ever use -p (ie., "add -p", "reset -p" and "checkout -p") and use it to construct the commit out of parts.

The way I work, I split my current work into multiple commits. I may have implemented a feature, fixed a bug I found along the way in the same file, and updated the readme with something unrelated; those are three separate commits. I do "add -p" to pick the fragments, and when I'm happy, I commit. Repeat until repo is clean.

Sometimes, my current work results in a whole bunch of such commits. Sometimes I have to split part of my current work into a separate branch. Again: Stage stuff, stash -k, checkout new branch, commit as a WIP commit, go back, unstash.

Darcs has "record", which is like "add -p" except it also commits at the same time, and back when I was using it, I remember hating the fact that it required that everything had to be recorded in one go. Git's incremental staging area is much more pleasant because you don't get stressed out by the impending commit that is looming over you.

I prefer to use shelving / stashing to do this sort of stuff. This way you don't need to learn two ways to do the same thing and you can be sure that the code version that you commit is the same that you ran your tests on.

In contrast, I never use `git stash`. Never-ever-ever-(ok-rarely). It bit me HARD early on, so I prefer to do it manually, or rebase branches.

One thing I really like about git is that it lets me be mindful of my actions in a way that hg didn't seem to encourage. In return, it gives me what feels like True Power to recover from _any_ mistake. Wrong branch? Accidentally merged (and pushed) my master branch? No problem, they're just bookmarks to commits anyways.

Mercurial, by contrast, felt Rather Convenient, with occasional chasms of despair if you strayed too far from the path. It's possible that my high opinion of Git is mainly from the fact that it forced me to learn more, but it really feels more flexible. I always have the right tool for whatever I need, and I know why and how to use them.

> if even a handful of the people who now use Git had learned both Git and Mercurial and made an informed choice between them. That simply does not appear to be the case. Git got ahead because Linus invented it, and won because of GitHub.

I think you also underestimate the developer community (or may I overestimate them.) Regardless, my anecdotal evidence is that I did try HG and Git, and while I preferred HG when I first started evaluating them, as soon as I found out how to use Git branches, it was all over for HG. At work we currently inherited a project in HG and everyone that has to work on it complains about it. Some know Git, some are .Net or even old school CVS/SVN people (our VCS migration took a bit longer than it should have), but it doesn't matter. HG = hard to use for them, whereas Git make sense after getting over the initial hurdles. I see the same kind of path I took, where at first they are like, oh, Hg isn't bad, and then after using both, choosing Git as their preference.

I used Mercurial for years because I tried early git and didn't like it. Then I tried it again, everything was easier than Mercurial and I wouldn't ever go back.

Hey, if you don't use the index then don't use the index. Use git commit -a. If you wan't something like the index in Mercurial you have to specify which files you want to commit, or which to exclude, which IMHO is a lot more tedious and error prone. Then again I haven't used Hg in a couple of years, could be they have something like the index now.

Rebase is a hack? Rebase copies a series of commits on top of an immutable history at a certain point in time. This allows you to deal with merges a single conflict at a time, instead of dealing with all the conflicts at once with a merge. It also allows you to avoid cluttering your history with useless merge-commits when just syncing with another repo.

Merges have their place. I use them whenever I merge branches, using --no-ff so I can attach a "Fixes issue #77" in the merge commit message. Of course, before I do that, I sync the branch I'm merging into, then rebase on top of that (to have a clean merge). I might also rebase --interactive to clean up the commits of my branch, so that the history is as easy to read as possible.

Comparing rebase to rollback is wrong. Git has rollback (or revert) as well, and it's used for other usecases, like when reverting changes on a public branch (where rebase would fuck it up for everyone).

I'm sorry, but your comments make it sound like you don't really understand Git.

>Rebase allows you to deal with merges a single conflict at a time, instead of dealing with all the conflicts at once with a merge...

Not sure what you mean by 'deal with a single conflict at a time'. To rebase or merge, you will have to resolve all conflicts that merge/rebase produce, right?

Yes, but a rebase re-applies every commit to the new base. So you solve conflicts one commit at a time, instead of solving every conflict in a single merge commit.

It's easier to remember the intended behaviour when the code changes are as small as possible, and when you have a (hopefully) good commit message to look at.

I am not sure it make any difference to the user at all. If you use a merge tool, it will present the conflicts one at a time for merging and re-basing.

If you are concerned about reading history, then a merge can give you more context regarding the commits. With re base, commits will jump between features. For example, You are looking at commit for feature 1, but the next series of commits are for a bug fix in feature 2. Next series of commits belong to minor tweaks in feature 3..

A merge will provide you with a single commit-message, rebasing will provide you a commit-message for every commit, making it easier to remember what the intent of a change was. Sometimes that isn't clear.

Regarding the "rebase, commits will jump between features" part: that really depends on how you do things. On my projects, we use git flow. In such a scheme, every branch you would rebase, belongs to the same feature or bugfix.

>In such a scheme, every branch you would rebase, belongs to the same feature or bugfix..

Not sure if I made that clear. But I was talking about the result of the rebase. Once you rebase, all the commits that were in different branch ends up being back to back, and hence become interleaved...

>Git won because it's workflow is so much better than mercurial's.

This is quite subjective. A more probable reason is that git is popular because of github..

And once git gained some popularity, people started viewing other DVCS as inferior because they were doing things differently from Git. For eg, the branching in Mercurial. People are appalled when they see how named branches can be done in Mercurial. Without going into any thought or reflection on how Mercurial's named branching can be useful in certain situations, they call it braindead. But actually git's branching is quite simple and less powerful than the methods offered by Mercurial. Less powerful, because Mercurial offers multiple methods to make a branch so that you can use the right one for a particular situtation. Note that this actually asks for more experience from the user. He needs to have experience with using each of these methods and should know how each of them may be useful in the future. It also stores more metadata and tools like revset which lets you to build powerful queries. So in that sense, Mercurial is also more complex than Git. But that is in a good way and unlike git's, it is not the complexity that gets in your way.

So in short, I think git is actually quite simple than Mercurial, but hides that simplicity behind a complex interface with non-intuitive naming and weird combination of flags and stuff. This causes the 'Aha' moments when one can finally see the simplicity that hides behind that interface, which trigger a huge release of Dopamine and prompts the user to write his own set of Git revelations that (used to) flood the internet, which in turn increases the popularity of Git...

"I underestimated how good it makes people feel to understand something incredibly complicated"

Or rather (in many cases) how good it makes people feel to use and tell other people they use something incredibly complicated, whether they actually understand it or not.

I'd venture that a fairly large amount of the people who use git don't really understand it fully, they just understand some very small subset of what they picked up from whatever "best git flow" website or book they happened to read.

Lest anyone think I'm being elitist here, I'll come right out and admit there's a ton of stuff in git I've never bothered to really understand. I'm okay with standard push/pull commits, stashing and rebasing, but I still kinda think of these things as sort of interpretations of concepts I'm used to from older non-DVCS systems, I don't "grok" git, not really -- never really bothered since I find source control systems incredibly useful but not inherently interesting (to me personally).

All that said, I don't use git to show off, I use it because virtually everyone else does and there is a certain pragmatic benefit to going with the flow on something like that even if I think it is overkill for a lot of the projects I need a VCS for.

Here's an interesting paper that largely confirms your supposition:

https://static.googleusercontent.com/media/research.google.c...

It was performance that made git win initially. In benchmarks git did better in the past when there was still a great Cambrian explosion of DVCSs (Monotone, Bazaar, Hg, Git, Darcs,...)

It is of course possible that performance follows a saddle like curve (or hump depending on how you look at it). For up to some size, git is faster. But at much larger ones a different algorithm wins out and hg could be end up being faster.

> I was really surprised that Git "won" because I thought that Mercurial's friendlier CLI and being written in Python would give it an advantage.

What we've learned is that these two things are actually liabilities.

git is a good example that the syntax of the command line is of no consequence. git's CLI is notoriously horrendous and bizarre, yet it didn't stop its adoption. And this is a problem that's easily worked around by creating tools (graphical ones and also porcelaines) around it.

The fact that Mercurial is written in Python has a big impact on its performance, and git is running rings around it as a result. When you run tens of commands every day, it adds up.

Strangely enough even git's initial hostility to running on Windows didn't stop its adoption.

git's features and modeling of source control system is so powerful and flexible that git became successful in spite of all these other aspects.

Frankly, I think it's silly to use any other source control these days: embrace git and get used to it because it's going to be around for a while.

> The fact that Mercurial is written in Python has a big impact on its performance, and git is running rings around it as a result. When you run tens of commands every day, it adds up.

This wasn't the case at all. In their early years, some operations were faster on git, and others, faster on Mercurial[1]. I don't remember any recent benchmarks, but early last year, there were reports of Facebook making Mercurial faster [2].

> Frankly, I think it's silly to use any other source control these days

You might get that impression if your work is centered around github, but I have friends who use enterprise-specific extensions on Mercurial that structure their workflow.

[1] http://draketo.de/proj/hg-vs-git-server/test-results.html

[2] http://www.infoq.com/news/2014/01/facebook-scaling-hg

You're not really disputing what I said: Mercurial is much, much slower than Git. Facebook forked it and managed to make it faster but they never released their fork so nobody can actually use it.

The bottom line is that a program written in C will always be orders of magnitude faster than a program written in Python. This is not news.

And why parts of it are written in C.

> You're not really disputing what I said: Mercurial is much, much slower than Git.

Yes, I am. And I gave a reference for it.

> Facebook forked it and managed to make it faster but they never released their fork so nobody can actually use it.

I invite you to look up the license that Mercurial is released under. And then I advise you read [3]. And why do you keep making these unsubstantiated claims?

> The bottom line is that a program written in C will always be orders of magnitude faster than a program written in Python. This is not news.

If we're comparing exactly the same algorithms implemented in both Python and C, C would usually be faster. But we are not discussing the implementation of simple algorithms. We are talking about complex software, with different architectures.

[3] https://code.facebook.com/posts/218678814984400/scaling-merc...

"The fact that Mercurial is written in Python has a big impact on its performance, and git is running rings around it as a result. When you run tens of commands every day, it adds up."

No, it doesn't.

The friendliness in the mercurial CLI ceased to be an advantage just a few years after git came out, IMHO. git error messages got better. I had to re-use mercurial after leaving it for git at one workplace, and I was cringing most of the time.

The main problem is that mercurial never got real branches, which is git's wheelhouse, forcing gross things like the "forest" extension (which I believe is now unmaintained). Maybe it's gotten better since then, but this was about 3-4 years ago.

The way I see it, git has all the powertools you'd need, and you don't have to use them most of the time, where as mercurial feels generally stripped down to be "easy", and when you want to do the hard things, it's not so good at it.

One of those examples might be something like grafting a repo into another repo at a arbitrary root, or some of the tricks you can do to edit previous commits (say if you mispelled your username all the way down).

My main point of switching originally was when I believe it mixed up a lot of commits in a merge and lost some changes. I also recall hearing about a patch for predictable ordering in diff output being rejected.

git's really gotten TONS better -- way back, I would say mercurial was easier to use, and git really excels at branch based workflows which at this point I can't live without.

Of course, a worse thing from having to work at a mercurial shop after loving git is having to work at a SVN shop :)

This attitude of "oh, the only reason it's popular is because people want to feel superior for learning something hard" is poisonous to productive discussion. If you're going to be cynical about it, at least favor the "OMG Linus Torvalds maed it" explanation over the one that requires active assholery on the part of Git users. Better yet, try assuming that most people are making a reasonable effort to be rational based on their limited knowledge. But what you did right there, please don't do that.

Anecdotal of course, but in my limited experience, I've seen plenty of superiority complexes and generally assholery, but no Linus fanboyism. I don't like it, but to me it seems like a perfectly unsurprising aspect of the software industry.

Your idea (my interpretation) that the industry mostly consists of people having productive discussions seems more off base. Yes, that's the way it should be, and usually is on HN and similar forums, but out in the larger real world, arrogance, superiority, etc are the order of the day.

Yes, I know the real world sucks. In light of that, let's try not to actively make it worse. Applying Hanlon's Razor aggressively is the easiest thing we can do. And don't forget the selection bias from the fact that jerks are more likely to make themselves noticed than rational people.

If I'm reading this thread correctly, hg doesn't even have a staging area! And you've got to come up with some far-fetched conspiracy theory?

Or you could mention the elephant in the room, the fact that git is orders of magnitude faster than mercurial when your project grows beyond the "small" size. Mercurial would be unusable on something like the Linux kernel, and uncomfortably slow on a lot of other projects. And big projects tend to have more developer mindshare-- funny how that works...

Except there are large projects using Mercurial without issue. See Facebook for example. If you want to look at open source projects, all of Mozilla uses mercurial[0] with just the standard hg-web server. And it's size is comparable (same order of magnitude) as the linux kernel)[1].

If you want to make such claims, I'd love to see data backing it up.

[0] https://hg.mozilla.org/

[1] https://www.openhub.net/p/compare?project_0=Mozilla+Firefox&...

Totally agree. Mercurial really is the product that deserves the spot that Git has claimed in terms of being the defacto DVCS. It's generally easier to use, well supported, and more intuitive. The good thing is that there is still a healthy competition out there to push ease of use and features forward. I think promoting Mercurial to help it gain market share is important. You don't have to suffer through Git!

What a silly comment. If using git is suffering to you, then don't. You know what? I hate peas. You know what else? I don't eat them.

You know why git won? HG was slow as molasses when they both showed up on the scene. That and git's branches are a dream come true. I think back then, an HG branch was a clone of the repo.

I can't figure out what sort of suffering people are talking about.

Well, we can't avoid git. Being allergic to git is like being allergic to water.

There are ways around it like hg-git, but they can't really hide the git underneath. We have to use git or be computer hermits.

Same story here. I learned both Git and HG circa 2007 and decided HG had a more pure DVCS model. I still believe that's the case and still use HG. When I interact with GitHub I use hg-git. Long time Git users: I strongly encourage you to try Mercurial.

Every time I try HG, I find that to do what I want I have to get a bunch of plugins. When I use a VCS, I want to know that I'm using the same commands as everyone else, so that we are all speaking the same language.

Most of the git commands I use are about as straight forward and simple as they could be. If ever I manage to screw something up, the archeology commands I end up using are obtuse, but it's rare that I need them. And I'm glad they are there when I do.

Are they plugins that you just enable in the conf file? If so, all extensions that ship with mercurial are fully supported features. They just disable parts of the cli that can be dangerous or are less commonly used.

If you are having to download 3rd party extensions, then that's a different problem.

I've learned git first and found Mercurial hard to use.

I've somehow created a branch that couldn't be deleted. Instead of being really deleted it appeared in remote repository as some kind of a "tombstone".

I've tried to rebase, but to do that I had to fiddle with settings and enable plugins.

My impression was that Mercurial is a higher-level version of git, with the sugary layer doing things that I don't want.

> I've somehow created a branch that couldn't be deleted.

The problem here is one of conflicting terminology. What Git calls a branch, no other version control system calls a branch. A branch in Git is really a moving pointer to the head of a branch as other VCSs would see it.

The confusion can go both ways, by the way. I.e. when a user who is used to another VCS expects a branch to be a persistent label for a set of commits and then discovers that it doesn't work like that for Git repositories and that your branches may "move" or "disappear" and don't even describe sets of commits but individual commits.

SVN tags and branches correspond quite closely to Git tags and branches, I think; "tag" is a naming of a commit, "branch" is an evolving repository that shares history (and perhaps future, if merged) with other such "branches".

Except Git tracks history of the named branch in the reflog, and SVN (and others, I would guess) track it inside the repository. This is a huge difference for archeologists, but quite minor in practice from my experience.

In SVN there really is no technical difference between a tag and a branch IIRC, although their intended usages are different, as you say.

To the point where it's almost easiest to say SVN doesn't have branches or tags - it just has directories and conventions.

Git doesn't really have a technical difference between a tag and a branch either. They are both files containing a hash for some commit. Tags are just more cumbersome to move (branches are moved on new commits), and they can be signed cryptologically(is that a word?).

Wow, I am not the only one :). For closed-source projects BitBucket is a no-brainer.

Bitbucket supports both mercurial and git.

Similar story here. I had been using hg almost exclusively for the past 5 years, not just for personal side projects but also at work with teams using git, thanks to hg-git. Admittedly hg-git had/has its issues, especially slower push/pull performance compared to both standalone hg and git, and occasional friction with the rest team that was using git exclusively. I tried to grok git during this time and gave up more than once out of frustration.

Eventually, just less than a year ago, I bit the bullet and made the switch to git. What did the trick for me was a list of short aliases I copied from somewhere, tweaked and have been maintaining in my ~/.bash_aliases ever since. Some aliases are just shortcuts for super common commands (such as "alias gts='git status'") but others remove the burden of remembering what combination of commands and arguments make sense to me ("do i undo a change with revert, reset, checkout or something else? well it depends.."). I still can't claim I know git in depth but it's good enough for day to day usage.

> get the hg-git plugin to work seamlessly with newer versions of Mercurial on Windows and Linux

Can you elaborate and/or point to an issue tracker that describes the problems?

The Windows malfunction may be more work than a reasonable person would want to bite off, but getting it to work on Linux should be feasible.

What are the big wins of Mercurial vs Git?

I find Mercurial easier to use, even though I use git much more. I also find it harder to shoot myself in the foot with Mercurial - I've destroyed (but not lost) work with git quite a few times.

Mecurial is super easy to learn - there is no reason not to be comfortable with both.

I've shot myself in the foot a few times with git, however, git reflog is _often_ there to help.

> I've shot myself in the foot a few times with git, however, git reflog is _often_ there to help.

Many times this. Git reflog is an extremely powerful feature to fix mistakes. Any git user should at least in base understand what the reflog is and how it can be used for roll-backs.

I don't know what the wins of hg are. Used it for a year

Git has git style branches which make it really easy to work on different things. Apparently hg added some of that later but it's not the main workflow

git also has a "staging area". You put things into the staging area and then commit. So for example the equivalent of "hg commit" in git is "git commit -a". The -a means "copy everything that's changed to the staging area".

The advantage of the staging area is it's easy to commit just a few files even if many have changed. It's even easy to commit just a few changed lines from a file and leave the other lines un-commmited.

There are other advantages I'm sure and I'm sure I didn't explain the branching one well. I can point out that I have repos with completely unrelated branches. One branch is the website, another branch is the docs, another branch is the source code, branches in hg, at least the default ones, are assumed to be something that will eventually be merged back. hg complains forever until you merge the branch back. git branches are effectively unrelated to each other, although by default git will track where it branched and if you happen to merge them where they merged. branches can be pushed and pulled to other repos or not, it's up to you.

Someone above said hg has bookmarks that are similar to git branches but I'd be curious if they're actually the same.

Interesting. I started in hg for a year then switched to git. It took a while to get used to but once I did I never wanted to go back to hg.

I've heard hg since then has added features that make it possible to have a more git like workflow but AFAICT it's still not the "recommended" at least not the default workflow which means I have no desire to switch back.

Reply on news.ycombinator.com