Hacker News Reader

Comment by bartread | Hacker News Reader

It's really strange to me that nowadays source control seems to be, largely, a monoculture. Back in the day I either used, or knew plenty of people using any of CVS, Subversion, Sourcesafe, Sourcegear Vault, Perforce, AccuRev, ClearCase, along with a few others.

Whilst distributed version control is a huge leap forward over many of those older systems, it's odd that nowadays it seems to be git or, well, nothing. I'm surprised Mercurial hasn't made more headway than it has.

But maybe git is just "good enough" for most people? I suppose that's where I land on it. It has it's frustrations, like anything else, but I can live with them.

View on HN

A large part, I believe, is the ease of moving a git repository around. Back in the day, the central repository was a choice that stuck you to it for a long time. You literally had to setup the server, in many cases. Git, though? You just install the client and you can get started on a repository in your current directory that can easily transition to a remote hosted one.

So, in a way, it is not unlike pathogen spread. Low barrier to get started combined with basically frictionless ability to spread out. Even the hiccups people used to have only slowed individual level adoption. (Complaints about the UI and such.) The spread of currently successful repositories was not really slowed by those events.

I'd be highly interested in if anyone has something like this modeled.

I'd also appreciate challenges to my point. Mercurial, I believe, should have had similar strength in spreading. It just didn't have the bootstrapped successful project like git. (The kernel, is what I'm thinking of.)

Mercurial had major projects too. Mozilla still uses it. What it didn't have was GitHub.

Good counterpoint! Oddly, in my mind, Mozilla is not nearly as new dev friendly as the kernel is. I suspect that is just a bias in my thinking, though.

I feel that git was winning a lot of mindshare even before github. I know I certainly was using it before github. Big plus for me was the git-svn bridge that existed. Especially since I was working remotely at the time, it was much faster for me to do checkouts with a git-svn clone than to deal with raw svn checkouts. It wasn't even close. Did git beat Mercurial to that?

Git was popular in some influential circles before GitHub, but it only became a monoculture several years later. hgsubversion came out in 2008, after git-svn but before most people were using any DVCS. Also, SVK was around before git-svn.

You might be underestimating how much support Mercurial had in the late 2000s. Mozilla, Sun, Google, and Microsoft all picked Mercurial over Git. Even GitHub published hg-git so people could use the Mercurial client with Git repos. Some ecosystems gravitated to Git (Linux, Perl, Ruby) and some gravitated to Mercurial (Windows, Java, Python).

By 2010, DVCS comparisons consistently cited GitHub's UX and network effects as significant advantages for Git. Atlassian, Google, and Microsoft all added Git hosting in 2012. By 2015, Python, Google, and Microsoft moved to GitHub because everyone else was on GitHub.

I think the landscape would look very different if GitHub hadn't come along when it did or had added Mercurial support instead of Subversion.

Sometimes it's just worth getting everybody on board rather than having the perfect tool.

Maybe in 50 years there will only be one package format for applications across the major operating systems. One can dream.

The irony of a decentralized version control system centralizing SCM usage to a single SCM and to a single SCM hoster, basically. Github dwarfs the alternatives.

In Mercurial (circa 2016) Tags and branches were stored inside the repo itself, which meant you had to switch to the master branch to create a new branch or create a tag. If you created a tag in a branch the tag was visible only when you were in that branch. It caused numerous headaches trying to figure out why a tag didn't get pushed upstream.

Git correctly treats this as metadata and stores it outside of the source repo itself.

Your description is correct for tags, a little off for branches.

You don't have to switch to master to create a branch, you have to switch to the branch you want to branch off of, which is the same as git. Also, all branches are visible and accessible from any branch/revision, unlike tags.

Git does default to the current HEAD, but it allows you to specify a start point if you want to. Doing this with git branch might be useful if you have changes you haven't committed and can't git stash for some reason.

See man git-branch and man git-checkout for details.

Git is not the same in this case. Since git branches are just refs, I can do whatever commits or other changes I want and then assign a branch name. With hg every commit you make must first be done on the branch you want. This, when understood fully, can allow git to be much more flexible when manipulating the tree.

If you don't want mercurial named branches then don't use them. Use mercurial bookmarks instead. They can do everything a git branch can do. Mercurial also has anonymous heads that actually allow Mercurial to be much more flexible than git.

You can rebase mercurial commits to a branch after the fact. As others point out you can also use bookmarks that are very similar to git branches, and you can also commit with no branch or bookmark at all and mercurial won't hide or garbage collect those commits (unless you tell it too). It's actually more flexible than git.

Reply on news.ycombinator.com