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.
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.
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.
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 haven't used git on Windows for some time now so maybe things have changed, but at that time, it was pretty obvious that Mercurial was a polished first-class citizen of the Windows platform while git was an incomplete port (and in git's defense, I don't believe "make it work on Windows" was ever a design consideration when it was written).
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.
I struggled with Git on Windows for months, I really don't remember all the problems I had right now, but here are some:
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
Surely the importance of that varies wildly depending on what you're doing? What percentage of developers even code publicly? I'd imagine that the vast, vast majority of businesses do not.
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.
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.
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.
I don't see any way of sorting by tags. We also use tags for several other things so it wouldn't even know which tags to sort by.
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:
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.
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?
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.
I am aware why the distinction exists - from the perspective of "git(1) manipulates the git file system", it make sense (as I wrote). But most people I know tend to use "branch" for all their branching work (as the name implies) and never bother about the finer details. But the fact that this sore point exists and is real makes the git UI problematic. I don't bother, because I know the details, but if I have to explain it to every new guy in the office, there is something wrong.
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.
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`.
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."
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.
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.
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.
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.
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.
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]
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.
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.
>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
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.
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.
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.
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...
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).