Mercurial vs Git: Why Mercurial?
blogs.atlassian.com
blogs.atlassian.com
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).
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.
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 :(
Shelf isn't that necessary because of mq, which is bundled by default. It is very feasible to use mq as a simple shelf substitute, much easier than using it for its more complex usage scenarios. Also, for your use case, it's pretty easy to hg diff your change to a file, switch branches, and then use the GNU patch command to apply your changes on top again, so you don't even need shelf or mq to do that if you haven't checked anything in.
"it's pretty easy to hg diff your change to a file, switch branches, and then use the GNU patch command to apply your changes on top again" It feels like mercurial developers wanted to inflict pain on me, and makes me want to hurt them in return. See, it's three steps. It's four actually, because you also want to delete the diff file.
You know how many steps did it take in SVN? Zero. When you switched branch, it just preserved all your changes and applied those back. You didn't have to do anything.
Maybe it didn't work when there was a conflict - once per 100 switches. But mercurial won't let you do that - that's 100 per 100 switches.
hg update <branchname>
do
hg update default
get:
abort: crosses branches (merge branches or use --clean to discard changes)
So?
cd $PROJECT
svn diff > ~/working-on-foo.patch
svn revert *
patch < ~/working-on-bar.patch
30 GOTO 10.
Git (as Linus says) is a STUPID content tracker. 99.9% of the time when I'm working on source code, git allowing me to do stable, local "bookmarks", keep multiple local branches (and local history) active simultaneously, and keep all my content tracked... Git has its flaws and warts but don't seriously suggest that "svn diff > ~/working-on-foo.patch" is a valid workflow. That's bringing a knife to a gunfight.
I suggest that if you can understand a linked list, you can understand git. And if you're a programmer that can't understand a linked list... well... print out your "cheat sheet", here's a copy of Tortoise, and commit your code to a branch before it gets approved for main-line.
Mercurial has remote-trackable bookmarks now (something I felt they needed for a long time). I agree Mercurial's branch tracking in general isn't nearly as good as git's, local branches being the biggest example. There is a local branch extension for mercurial (http://mercurial.selenic.com/wiki/LocalbranchExtension), but having used it a long time ago I'm not sure I'm the biggest fan.
However, I firmly believe that mercurial is in the same league as git and both are more than good enough to get the job done, and each have their relative strengths and weaknesses. I also believe that the outspoken part of the git community tends to be overzealous and blind to git's faults and Mercurial's strengths.
Because sometimes simplicity is a good thing? I'm not a Mercurial user, but there are plenty of times when decoupling features is a good thing- look at Mozilla Communicator Suite (or whatever it was called) vs. Firefox.
For the record, I use git every day and I'm yet to need rebase. No, my projects aren't all that complex, nor do they have a huge number of branches. But I suspect that is the case for a lot of other people, too.
If you don't use branches much (like most github users) you probably don't have this problem. We have version branches, so I do.
When I use git (I tend to use hg more because it's more friendly for Windows projects, where I often find myself), I generally work on master for personal projects where I'm the only committer. It's easier for that use case. Branches are primarily valuable, IMO, when you have multiple people bashing on it at once.
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.
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.
- 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].
"Git encourages micro-management, and git’s users end up loving this micro-management (and blog about it, and write books, and have conferences, and so on ad-nauseum). This is characteristic of the perversion that git promotes, focussing on details instead of getting work done."
What does the author know about how much work any of those people get done? But I'm glad he wrote that; it made me feel much better about writing the rest off as a rant.
Regarding sunk costs, that's true of pretty much any sufficiently complex tool or technology. You could make the same case with Emacs vs. vi, or pretty much any programming language, API, or framework.
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.
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.
Another time came when I was trying to squash changesets, I managed to futz around with it to the point of absolutely killing a changeset. I don't know how I did that.
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]".
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.
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.
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.
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...
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?
I presume things have changed since then but it wasn't always the case.
Git for windows basically brings half of MinGW with it including a shell and pisses up your windows cmd settings terribly. There is no platform abstraction layer in Git, so you're stuck with dragging GNU with you (it's not even POSIX compliant).
Mercurial is far more respectiful as it uses Python as the platform abstraction layer, uses windows semantics quite happily and considered Windows very early on.
Mercurial is just more polished on Windows.
Also the IDE integration and tooling on Windows is an order of magnitude better. It just works with no fannying around.
Add to that it's considerably less cryptic than Git and it's won.
Proxy support: Setting up git to work under a proxy was a pain. I had to switch my proxy configuration all the time due to the company firewall and I remember had lots of throttle making Git recognize it.
Integration with other tools: Since the windows Git requires a custom shell, its harder to integrate with other tools E.g. I had to track down and fix issues like this: https://github.com/fschulze/mr.developer/pull/53
SSH: It required putty pageant! the horror! getting SSH to work under a proxy was impossible.
Mercurial is superior because it's easier to port to other platforms, probably because its written in Python instead of C and shell scripts. Mercurial doesn't requires a MinGW hack in order to run.
Github brings us no benefit then.
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.
Is that not your experience?
We currently have 9 people accessing our 12 source repositories (9 BitBucket users or 9 GitHub collaborators). With BitBucket we pay 10USD/month, with GitHub we would have to pay either 22USD/month (the Medium plan) or 25USD/month (the Bronze plan).
In the end, BitBucket's pricing structure is much simpler for us and fits our model much better.
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.
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.
trac does a really good job on this side of things, especially a nice place to provide (and sort) milestones, show their progress, a little bit of writeup etc. This is an example:
Github is no doubt useful, but don't ignore the others -- this is not facebook.
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.
git add/rm handles making changes to the index and there is no similar concept in mercurial or subversion.
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?
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.
About git add -p: yes, I am aware of -i, but it doesn't give you the easy "give me all changes to the file system and let me sign them off"-interaction that git add -p has. They are two completely different interaction modes.
5<enter>
*<enter>(all changed files) or 1-5<enter>(files 1-5 in the list) or 1,5,3<enter>(files 1, 5 and 3) etc...
then <enter> gets you to the staging that you are used to. this will get you into the quick patch mode that -p does.
-p is just a short circuit of this.
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.
almost never. Details below:
http://stackoverflow.com/questions/1314668/git-repository-ba...
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.
* 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.
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-...
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.
"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
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?
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.
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
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.
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.
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...