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).
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.
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.
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 :(
Your comments highly suggest that you are not by any means a knowledgable mercurial user. You don't have to "assemble" mercurial from parts to do history rewriting. Enabling the relevant extensions amounts to adding a single line to a config file. I usually copy the same config file around when installing mercurial anew so that I can cut out even that step.
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.
Ugh. Thinking about going back to that workflow makes me physically ill.
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.
I only suggested the diff/patch workflow for the simple case where you realized after making edits that you were in the wrong branch. It might even be possible to just update to the correct branch and have mercurial automatically try to remerge your changes, though I haven't tried to know for certain. I think you're taking my suggestion way out of context, though I could be misunderstanding you.
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.
Well, if I need to turn on a few extensions and download obscure python scripts just to get the minimum viable experience, I consider the "Lego" badge mine.
"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.
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.
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.
Not sure he's accurate when referring to Github users, but I think he's probably not far off for git users in general. I mean, most git users aren't the people hanging around here. I don't see a reason to expect that more than "the simplest thing that could possibly work" to be commonplace.
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 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.
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.
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].
"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.
Gitology is definitely a sunk cost, because of all the concepts you have to learn which are not applicable anywhere else. Here's a good example of what happens when a programmer learns git as the first DVCS:
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.
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.
I like visualizing my graph tree in a GUI, so I grabbed GitX for Mac. I was trying to move my 'working directory' (hg term for the rev you're pointed at) to an earlier rev, so I used a 'hard reset of branch' option. Zoom. Away went my changesets, with me not having any idea how to scrape them up again. I think with enough google-fu I could have found them, but I had the files in my editor, so the issue was resolved.
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.
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).