Hacker News Reader

I'm a pious hg user - even gave git a good run (mostly because of Github). I can't get over how amazing mercurial patch-queues are. Big win. I love mercurial's easy plugin development and hooks (thank you Python); I love how many awesome plugins exist for mercurial. On and on and on.

I keep seeing people talk about all the good of hg over git, but I haven't seen anything that really sets it apart.

If you were doing a sales pitch, what would you show that hg has over git? What are some specific plugins that ease your development or release process? What are some real-world advantages of the hg patch-queue over how git handles pulls?

I'm honestly curious. I just haven't seen anything to sell me on why hg is so much better than git (or even the other way around).

From the perspective of a longtime hg user who switched jobs and is now in git land: hg is easier to pick up and start using than git.

git lets you do incredible things with your tree, things that hg forbids or makes impossible. But git also lets you make big mistakes, and isn't very nice about helping you fix them.

hg, on the other hand, has a much nicer learning curve. As an example, try to forget everything you know about version control and type `hg help push` and `git help push`.

Which one would you be able to parse? Personally, when I read "The format of a <refspec> parameter is an optional plus +, followed by the source ref <src>, followed by a colon :, followed by the destination ref <dst>", I want to punch a baby.

At the end of the day, if I want to transition a team away from SVN onto a DVCS, I'd pick hg -- just because it lets a team Get Shit Done without spending a ton of time learning a new VCS. But if I'm starting my own project? I'd pick git in a heartbeat.

Besides the simplicity when starting to use a DVCS, i would add the simplicity for setting up a server (At least on Windows). There are a lot of organizations which need a centralized repo. And setting up mercurial for serving is a breeze. That's my 2 cents.

Next time you have to use git: Remember, there are also patch-queues for git.

/me did not know this - thank you for the fill in (I'll stop preaching about them for hg then, I thought they were unique to hg!)

Also mercurial can do almost anything that git does (and more) with the right extensions.

Nowadays the choice between git and mercurial comes down mostly to preferring on the user interface over another.

Which do you use? I've had a quick google and only found Guilt as a serious contender, and that doesn't seem to quite do what hg patch queues do (especially wrt publishing queues). I'm interested as it seems like quite a common workflow (for me at least) that doesn't really fit into the Git model.

Have you come across this discussion (http://stackoverflow.com/questions/5016862/whats-the-git-app...)?

My co-workers use Guilt.

We had published patch-queues in another department I worked for, and they were one of the reasons they switched to git instead.

I've never warmed up to patch-queues, but I haven't really tried to use them seriously.

I'm pretty addicted to git's lightweight branching now. Mercurial looks appealing in some ways but, from what I understand, it doesn't support anything similar, at least not in the core.

You are thinking of Bookmarks, which have been a part of core since 1.8 and was an extension included with mercurial for a few versions prior.

Bookmarks mimic git's branches to some extent, but last time I tried they did not cope well with complicated merges.

For heavier work, hg's patch queue's are unmatched. (not to mention you can version the patch queue as well!)

If bookmarks are too lightweight for something (say you have an experimental branch that you want to branch on-top of) patch queues are amazing.

Not to mention their ease of use!!

http://hgbook.red-bean.com/read/managing-change-with-mercuri...

I'm a Git guy myself, but FWIW: While Python seems to be the Mercurial project everyone remembers because it was the most recent biggie to adopt it, there's also Mozilla, and the Ex-Sun-now-Oracle projects and a couple of others.

Ah, very interesting list.

I guess I think of Python differently from the other projects in your list because the choice of DVCS chosen by the core team seems to me to impact the DVCS that someone will choose for their library in the language. I don't really have any evidence for that, however.

Do you think that (a) language communities tend to standardize on the same version control, and if so, (b) that language communities tend to standardize on the version control of the core project for the language?

I think (a) is true, yes. I've written about the migration of KDE from SVN to Git in a longer comment elsewhere in this thread, and Qt (not a language, but the library framework most of KDE's products build upon) switching to Git was definitely a significant factor in Git gaining traction among members of the KDE community. The KDE community consciously wanted to harness the potential synergy it saw in the KDE and Qt ecospheres syncing up on the same VCS.

OTOH, I think the Python community is pragmatic enough that it wouldn't have chosen Mercurial over Git if it being written in Python would have been the only point in Mercurial's favor, from the POV of their requirement set. But it probably does have an emotional/affinity effect, after all language developers do obviously have to care about language! :)

Interestingly, one of the best Git libraries around is actually a pure Python implementation of Git and its protocols: Dulwich.

As someone who choose hg over git w/o reviewing bitbucket vs github, I'm curious what makes github superior. Can you elaborate?

It is difficult to answer your question without knowing your purposes and goals. What aspects do you think would make a quality version control host?

For me, the primary issue is size.

A large number of people use Github. This means that social features like networks of forks of repositories and pull requests are substantially more compelling. This also means that many related websites (bug trackers, project managers) have Github integration. Further, it makes much more sense to design custom desktop apps for Github because it is what everyone uses. Lastly, the more people are familiar with Github, the easier it becomes to suggest it for a project or to contribute to a random Github-based project.

The APIs, UI, and general flow of Github are competently designed, but I do not think these are necessarily the core of its success. (I do believe these parts of Github, however, to be better than the competition.)

Ultimately, Github is in a unique position because of its (and git's) popularity. Social features that would not work on other sites work on Github. I am sure that the developers and designers of, e.g., BitBucket and Google Code are smart people, but without users they feel a little like ghost towns.

This is odd, because I had thought of VCS hosting as very much a commodity before Github.

Git appears to be fast becoming the standard DVCS.

Whenever I read a statement about popularity of technology, the first thing I do is check the job ratios:

http://www.indeed.com/jobtrends?q=cvs%2C+subversion%2C+git&#...

Git has been picking up speed, but Subversion seems to be (nearly) matching its growth. This makes me feel slightly less bad that all my personal projects are checked into Subversion on Dreamhost. :-)

To add further evidence toward your argument, consider also the alternative name, "svn":

http://www.indeed.com/jobtrends?q=cvs%2C+subversion%2C+svn%2...

The popularity would actually be the sum of both.

Not necessarily. Some entries might refer to both but be in the same entry. So the correct way to calculate totals would be `subversion + svn - (subersion and svn)`

You're right, but in my experience any mention of subversion in a job description tends to only happen once in the document.

The following link should provide the correct unions of job postings:

http://www.indeed.com/jobtrends?q=git%2C+hg+or+mercurial%2C+...

You present an interesting tool for settling such debates. However, I believe the more appropriate URL would be:

http://www.indeed.com/jobtrends?q=git%2C+hg%2C+mercurial%2C+...

Obviously, cvs and svn will be with us for some time still, but those are not distributed version control systems (DVCS).

However, you raise a good question: is distributed version control so much better than centralized version control that we will all eventually be using a DVCS? Or are cvs and svn so much easier to understand for new and/or low quality developers that cvs, svn, and others will be with us forever?

> However, you raise a good question: is distributed version control so much better than centralized version control that we will all eventually be using a DVCS? Or are cvs and svn so much easier to understand for new and/or low quality developers that cvs, svn, and others will be with us forever?

Well, I guess I must be one of those low quality developers, as I have yet to hear/read a compelling argument that would motivate me not to use SVN.

I have always considered the source control problem to be solved: distributed version control attempts to solve a problem that I don't have, and never had while working on major projects with distributed teams in the past.

"is distributed version control so much better than centralized version control that we will all eventually be using a DVCS?"

I can't predict the future, but I do think DVCS is fundamentally superior. Joel Spolsky called it "possibly the biggest advance in software development technology in the ten years I’ve been writing articles here." (http://www.joelonsoftware.com/items/2010/03/17.html)

Let me describe a key weakness of centralized version control and how decentralizing fixes it.

Say you're working on a project with others. All of you commit to the repo, and you use it to deploy to production.

When you're coding experimentally, you have to make a choice: do I commit often, possibly giving half-baked code to my peers? Or do I commit only when I'm totally done, with long periods between commits, during which I can't roll back changes?

DVCS eliminates this painful choice. Commit as often as you like on your local repo. When your code is ready, push up to the shared repo. If you like, you can even do better: push up to a shared development branch for review and merging into the deployable branch. And better than that: if it took you 20 false steps to get to the end result, doing stuff, undoing it, redoing it differently, etc, you can clean up that commit history to a single, logical, readable commit for your teammates to read.

That is fundamentally better for teammwork. Add all the stuff about offline access, etc, and it's just clearly better.

DVCS eliminates this painful choice. Commit as often as you like on your local repo

I use Subversion or CVS. When I'm coding on a team, we're usually working on a branch of the code. Additionally, I'm typically working on my own branch of that branch, which is my own sandbox.

I check in whenever it makes any sense. My only rule is that the code must compile. When I reach a point where I want my peers to receive my code, I merge to the team's branch.

How is my process any different than using Git?

Your dev tree doesn't have to be always working so you can clean your commits later, you can commit much more often. Instead of using the VCS just for final collaboration you're now much more mobile. In a centralized VCS check-ins and branching are the sorts of things that risk breaking tests and require your team's awareness. With a DVCS you're the only one using it and can check-in every minute if you want, have all the experimental branches you need, etc.

Instead of copying files or some other manual filesystem manipulation to swap between lines of development you're using a tool to help you. Once you're free to branch around as you wish you can get even partial ideas into code - they don't block anything by not being complete.

Then you can clean up this dev rambling into the public commits you want everyone else to see - usually the whole side-project in a couple of larger (and often out of original order) commits. Here is where you make sure the tests are successful at each commit, that you reference bug numbers, write decent commit messages, etc.

And you can do this without anyone needing to know or help with anything until you finally have nice clean commits based off of the current tree and they get imported as nice atomic chunks. You can either ditch your ugly dev commits, or keep them without it getting in the way if you're a history junkie.

tl;dr Instead of a flat directory as your sandbox you've got a full VCS at your disposal.

In a centralized VCS check-ins and branching are the sorts of things that risk breaking tests and require your team's awareness

Huh? Branching code in no way affects the code that has been branched.

Instead of a flat directory as your sandbox you've got a full VCS at your disposal

I don't get it. I can make as many branches in Subversion as I want. It's pretty common for me to have a couple of active branches off the same parent, as I try a couple of different approaches to a problem.

So far, the only advantage I see to Git is the ability to make offline commits (presumably they sync when I have a network connection). But that's only an advantage in my hypothetical future where I'm developing code as I travel around the world.

> Branching code in no way affects the code that has been branched.

Usually it requires a repo admin - hence "team awareness".

> So far, the only advantage I see to Git is the ability to make offline commits

That's more important than you imagine. It also means nothing takes longer than a few seconds - branching, diffing, committing...

> I don't get it. I can make as many branches in Subversion as I want.

But you can't do it offline. You can't even check-in without the central server, let alone make and use branches, merge them, share them with another dev, etc.

When you're offline you aren't using a VCS at all.

> presumably they sync when I have a network connection

Hah, no. That's half the fun.

I can't speak for anyone else, but I would personally be extremely hesitant about taking a job anywhere that doesn't use a DVCS (and, realistically, for 'DVCS' read: Git or Hg). The technology an organisation uses says a lot about its culture. Anyone who hasn't switched to, or isn't in the process of switching to a DVCS is at a huge disadvantage.

Anyone who hasn't switched to, or isn't in the process of switching to a DVCS is at a huge disadvantage.

In what way? I've dabbled with Git, but I don't see any advantage in it versus Subversion.

Are you serious? With a DVCS you can commit to a personal repository offline, this in itself is a killer feature. Git also tracks content rather than files which makes renaming so much less problematic when it comes to subsequent merges (and who likes merges?). Git has the concept of stashing changes enabling rapid context switches without losing work in progress. It is significantly faster. It uses less disk space for branches. Creating branches is much quicker due to a fundamentally different way of branching. Finally, it has a killer app in GitHub. What more do you want?

Are you serious?

Was that necessary?

As I said to billybob, when I work in cvs or Subversion, my team is working on a branch. Personally, I work on a branch of that branch. I check in anytime I like. When I want my teammates to receive my code, I merge back to the team branch. So, I don't really get the 'sandbox' advantage of git.

Speed and disk space have never been an issue for me with cvs or Subversion. The content-tracking sounds interesting, but really, I don't rename files all that often.

it has a killer app in GitHub

That doesn't have any sway on my choice of version control. I sometimes retrieve files from GitHub, but that's about it.

I don't know, I haven't heard anything really compelling about git. People who use it seem really excited about it, but not for any reasons that strike me as particularly objective.

Please accept my apologies, my original response was a little OTT. The objective reasons for making the switch are:

- its a lot faster (IIRC creating a branch in subversion is the same as a copy operation) - the merging algorithm is better (this is so important IMO) - you get to commit when disconnected from the network - because it is faster and uses significantly less space, you can improve the way you segregate changes, giving you more (and improved) options when it comes to your branching strategy