Hacker News new | comments | ask | show | jobs | submit login

Speaking as someone who used both Git and Mercurial, and who has used both to contribute to projects:

Git's concept of branches as simple names for commits, and the ability to switch branches really easily within one checkout (rather than encouraging the use of multiple working directories) helped hugely. Mercurial grew the ability to do git-style branching later, but git had it from the beginning.

Git has always treated performance as a first-class feature, and that has enabled certain types of workflows that Mercurial makes painful. Git is fast enough that many things don't feel like they take any time at all.

Git integrated first-class support for carefully constructing and reworking a set of patches to be sent by email. Mercurial again eventually grew such support, but early on, it was much more insistent that all branches must be kept around, and by the way are you sure you don't want to push your development branch experiments up to the server and keep them there forever since you haven't merged that head into the mainline?

Even later on, mercurial had more of the functionality people wanted but relegated it to "extensions", while Git shipped it out of the box.

Take a look at https://walac.github.io/mercurial-for-git-lovers/ (from 2015) for just one of many examples.

About 5 years ago I introduced multiple developers for DVCS, as we migrated away from TFS. I was used to Git, so we used it for a while because we might as well support the tool with the most traction. But after I had to unravel the state of a repository to save work for the 100th time, I assembled a small team to evaluate it. Our conclusion was clear, Git was not working. We rolled out Mercurial for a few projects and it just clicked for the guys, they even began using advanced workflows without central repositories.

So while it might be obvious for you why Git became most popular, I believe that today, it continues to be that way mostly because of GitHub.

I spent a lot of time getting a distributed team that was on a terrible proprietary source control system onto mercurial. Being able to just have them force push their changes and then fix it on my end was a great way to get people on board with it, while my experiences getting a team onto git included a lot of lost code.

> Git's ... ability to switch branches really easily within one checkout (rather than encouraging the use of multiple working directories)

As a heavy Mercurial user, but only for the last couple of years, I'm confused by this one. You can just as easily switch between branches (in the Mercurial sense) and bookmarks (which are Mercurial's name for Git-style branches). How did that used to be different?

In fact one of the nice thing about Mercurial is that you can easily switch to any commit and you don't need to choose between a hard reset and a detached head, because you can always make a commit anywhere (multiple heads for the same branch) and it will never get garbage collected (a foreign concept in Mercurial). Mostly this is good because you simply never need to understand what these concepts mean, which it turns out are not fundamental to DVCSs. But also this makes a neater alternative to stash (although stash is also available): just commit your half-finished changes, mark the revision "secret" (which means it won't be included in any push), then switch to another revision. You can always strip or rebase the revision later, so long as you haven't pushed it (admittedly these actions do require extensions, but they're included with all Mercurial installations).

Our workflow at work (with Mercurial) revolves heavily around multiple heads for a single branch and relating the commits to a JIRA issue is done by simply putting the issue number in the commit message. So we have (unnamed) feature branches and also no bookmarks for them. You just start from the latest release tag and create new commits. No need to think of a name for the feature branch, or telling the reviewer or issue tracker which bookmark belongs to that issue.

This might be mainly habit and familiarity with a different tool by now, but to me it's simpler than equivalent Git workflows as there's less ceremony involved to start working and there's no fear around accidentally losing commits because they don't belong to a branch (I kinda hate having to go into the Git reflog to find commits that are temporarily lost because they don't belong to a branch).

Well that is just about the strangest workflow I've heard of. It sure seems like you are throwing away a lot of the power of the tools to do things manually. Honestly, I don't see the point.

I've used Mercurial from the very beginning, the branches are great and bookmarks are fine. I see no reason why you wouldn't use them.

We use both, just not in the way a typical git workflow would use feature branches. Basically those are all anonymous heads on the same branch for us; a workflow that is probably as alien to git users as naming each and every head is to Mercurial users.

Bookmarks are a relatively recent addition to mercurial, but as you point out you could always easily switch to any commit. It's just that people didn't understand how to work that way early on. The recommended flow of mercurial in the early days was to have a clone per anonymous branch, or to use named branches, if I remember correctly.

We as a community of developers have learned a lot about the power of DVCS since git and mercurial got started. I'd say even the developers of those two tools have learned a lot since then.

>We as a community of developers have learned a lot about the power of DVCS since git and mercurial got started. I'd say even the developers of those two tools have learned a lot since then.

So are we going to have something better than both hg and Git? There hasn't been any new DVCS for a long time.

Pijul, hopefully

With agpl licence, it has a reduced chance to become mainstream, though.

It's a pity, because I like its technical ideas.

For small teams with a simple code-base Mercurial is a way to go. Being written in a readable language is just a cherry on top. If you eventually need those fancy features that Git provides you could always migrate later.

I'm a huge Hg fan, and this thread makes me miss it terribly, but being written in "a readable language" is pretty much negated by all of the shenanigans Mercurial has to pull (including a nontrivial amount of C and Rust) in order to be passably performant.

What is hg's underlying data model?

Abstractly, it's exactly the same as git. Commit → File tree → File data blob.

The underlying data structures used are different, but considered an internal detail, so could be changed in the future. Today, most data is stored in a "revlog", where data can be either be stored (compressed) directly or stored as a (compressed) delta against an earlier version. Deltas may be chained. The index consists of fixed size records, which gives fast lookups, which are also linked to global revision numbers so that you can eg quickly find the commit based on a specific file change.

Obs: This is based on attempting to re-implement the basics of Mercurial from scratch.

I'm not an expert in mercurial, and I'll defer to those who are.

My understanding is that while Git stores a tree of objects indexed by hash (and then packs them into packs along with an index, which can be repacked arbitrarily later on), Mercurial's primary data format is a log-structured list of revisions as deltas.

My impression was always that Mercurial wasn't entirely stable/reliable.

Especially the Windows port seemed rather prone to corruption.

>Especially the Windows port seemed rather prone to corruption.

Quite the opposite of my perception.

I started with git. Then I got a job and for a while I worked only in Windows. At the time, I looked into git for Windows, and while everyone said it was stable, everyone also said that it was unofficial - the Git development team had stated clearly they were not interested in maintaining a Windows version.

I didn't want to be in the position to justify an unofficial tool to my employer, so I looked at Mercurial - Windows support has been in there since the first day. So I switched to Mercurial. In almost a decade of using it on Windows, I have never had any problems.

Mercurial is great - I've never come across a use case where git is clearly better.

Unicode file names were a bit of a pain at one point. Haven't tried that again recently.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact