[interroboink]

I liked the thorough article, but my goodness did they beat around the bush w/regard to their actual contribution to this process (per the title).

I think the short version is: they made `git-cinnabar`, which is a git-to-hg translator, to help git users interact with the Mozilla repos.

----

One contribution I can make:

> For reasons I don't know, Mozilla decided to use separate Mercurial repositories as "branches".

Originally, separate clones was the recommended way to do "topic branches" in Mercurial (not to be confused with "named branches"). There was no direct equivalent to git's branches. Eventually, Mercurial got 'bookmarks' which basically closes that gap, but that only became a core feature in 2011, well after these Mozilla repos were established.

----

Aside: I prefer Mercurial myself, and I hope to keep using it for personal projects until I die (:

[crdrost]

> Aside: I prefer Mercurial myself, and I hope to keep using it for personal projects until I die (:

One of my favorite stories happened three or four jobs ago... at this job I kept a giant whiteboard that I had swiped from a conf room, behind my cubicle. And whenever anybody asked questions we put it up on the board. We were an SVN shop and someone had asked how Git worked and I was like "do you want me to explain Git, which is harder to understand, or Mercurial, which is basically the same but a little easier if you're coming from SVN?" and they said Mercurial. So that is how for a week or two a set of sketched diagrams sat around behind me describing Mercurial.

So while that was happening, I was in the middle of some big commit, this guy Cal comes over. Cal is, we'd classify him as nontechnical but he's essentially the Product Owner for the stuff I'm building, he's the one whose workflows the software needs to enable. And I motion to him that I need 5 minutes and finish my thought and save and commit and whatever else, take off my headphones and ask "what's up, Cal?"

He has been staring at the diagram for those minutes, bored, and this non-technical user says, "okay, so let me see if I got this straight, inside some folder there's another folder named dot-h-g that is a repo..." and goes on to explain everything about Mercurial from a simple diagram, except that he can't figure out what problem it solves. And so I tell him, "you know how on fileserv everybody has to back up every file by appending a timestamp? software developers use these commits instead, so that every commit tells you who changed it and they have to say why they changed it, and that's how you save it," and his eyes kind of go wide and he's like "why don't we have this?!" and I'm like "you could! let me show you TortoiseHg..." and he really liked it, and of course then couldn't convince anybody to actually use it. (There's a problem where you really need to lock, say, an XLSX file.)

Mercurial is always to my mind the version control system that a typical nontechnical office worker could appreciate just from looking at a whiteboard diagram.

[muxator]

> Aside: I prefer Mercurial myself, and I hope to keep using it for personal projects until I die (: ... > you could! let me show you TortoiseHg...

Same here. I use TortoiseHg daily and propose the occasional contribution when something breaks/can be improved. It is really a project that has been chugging away for more than 15 years now.

[happymellon]

There are plenty of nice GUIs for got as well.

TortoiseGit works, Fork is pretty good but it's a shame that GitKraken is so expensive.

[Fatnino]

You have to pay to use hg in gitkraken?

I use it for git all the time for free.

I liked hg a lot when I worked at a place that used it but I've since just sortof defaulted to git for my own stuff since that what everyone seems to be using.

[happymellon]

Last time I tried GitKraken it did not like anything vaguely private (with git) without trying to charge you a monthly subscription.

I pay for Jetbrains, so I'm not adverse to spending money on software, but I don't like subscription software like this.

[pjmlp]

I miss Mercurial, thankfully ToirtoiseGit is similar experience to the Mercurial and SVN clients, and like a large majority I just fix git issues by cloning from scratch as the famous xkcd comic.

[glandium]

Author here.

> my goodness did they beat around the bush w/regard to their actual contribution to this process (per the title).

Fair point. I came up with the title first. Then as the content grew large and diluted the essence of the title, I reconsidered, but ended up sticking to it as a shameless clickbait.

> Originally, separate clones was the recommended way to do "topic branches" in Mercurial (not to be confused with "named branches").

That still leaves the question "why topic branches rather than named branches?". For the needs of the rapid release process, named branches could have been used, but weren't. I haven't tried to contact the people involved at the time to have a definite answer. It's not /that/ important, and I'm not /that/ curious.

[lynguist]

What a beautiful post it has become nevertheless rivaling the long reads of the New Yorker and the like.

I originally wanted to go to sleep but the writing was too captivating to put down, and every paragraph was motivated, and it wasn’t stretched. It was the length it needed to be.

[LegNeato]

One of the Firefox rapid release designers here :-)

IIRC, topic branches were used because:

- Mercurial named branches were half baked at the time and I was advised against them by folks who knew hg better than me.

- We were already using separate clones for security update versions (3.5.x and 3.6.x) so we just kept doing the same. Some tooling could be reused.

- Rapid release was a big change and we didn't want to disrupt mozilla-central dev. Having rapid release in different clones got us out of the way and reduced the risk of negatively affecting development. m-c was the domain of developers, the rr repos were the domain of the release team.

[glandium]

Hey Christian! :)

[kbrosnan]

Tracking down preed, JST, joduin, bsmedberg, etc might turn up stories.

Some of it is captured by preed in https://soberbuildengineer.com/blog/2006/11/version-control-... and announcing hg in https://soberbuildengineer.com/blog/2007/04/version-control-...

JST post on bzr vs hg perf, https://web.archive.org/web/20070219012211/http://weblogs.mo...

[glandium]

If you look closely, I linked to preed's posts. :) (look for "colorful")

Jst's post is linked from the second one. (but is a dead link)

[maccard]

> Fair point. I came up with the title first. Then as the content grew large and diluted the essence of the title, I reconsidered, but ended up sticking to it as a shameless clickbait.

I enjoyed it. It could maybe have been two posts, but it's a headline, it's supposed to get you to click on it.

And it's true, too.

[pcwalton]

One of the biggest problems with Mercurial is that they took a long time for histedit to become a usable workflow. I speculate (without any evidence, so this could be entirely wrong) that this is because many Mercurial contributors preferred MQ over editing history for local patches. (Certainly I knew many Gecko developers who swore by MQ.)

Coming from Git, with the git rebase --interactive flow coupled with the reflog to provide a backup to let you undo any mistakes, MQ was awful. Your choices were (1) allow hg qrefresh to overwrite the old contents of your patches and hope you never made mistakes, or (2) make your patchqueue an hg repo and have to look at second-order diffs. (I chose option (3)--symlink my patchqueue into Dropbox so that I could use Dropbox's history feature as a kind of poor man's reflog.) And to top it all off, MQ didn't understand three-way merge logic the way git rebase does. This workflow seems to me clearly worse than Git's tools, and I'll never understand why so many developers at Mozilla claimed to prefer MQ over Git.

[jgraham]

Yes, I think it's under-appreciated how much git and mercurial were ideologically different in their attitudes to history rewriting.

The generally accepted narrative these days is that git became popular because of github (with the implicit assumption that was an arbitrary choice) and/or the Linux kernel (without much questioning of why people specifically cared about Linux's tooling for wource control).

But what I remember from ~2010 was a load of blog posts eulogizing history rewriting and how it allowed you to separate out the activities of committing changes locally in order to record the state of your work at various times, and assembling the final patch into something suitable for review by others.

Meanwhile mercurial took the stance that history rewriting is bad, and as a result people ended up using even worse solutions like `mq`, which is basically tooling around directories full of numbered patch files.

You still see that distinction in hg: once it eventually did realise that history editing is a desirable feature for many reasonable workflows it added a lot of additional complexity to the basic model, with features like phases (supposed to stop you rewriting commits that someone else might be depending on, but just using the proxy measure of "was this pushed to a 'publishing' repo") and "evolve" (which keeps a complete history of history rewrites; useful in principle for tools like code review systems to avoid the common pattern of putting a "patch id" into the commit message, but in practice felt like a lot of extra mental overhead).

So at least my view is that git made a "practicality beats purity" bet on history rewriting being a net good, and hg made the opposite bet, and eventually lost.

And back on the original topic, I used hg personally before I used git, and then professionally at Mozilla before git cinnabar came along (although by this point I was using git in other projects). So I've used mercurial a lot but actively prefer git when given a choice. Nevertheless I think this article understates just how good cinnabar is compared to the options that preceded it; apart from the case where you have a hg hash from an external system and want to find the commit locally (where you just run `git cinnabar hg2git`) it's basically totally seamless and just works without problems. It's a small tool that does one thing really well, to the extent that it's easy to overlook just how good it really is.

[interroboink]

I can't speak for those other people, but as someone who likes MQ (even today!) I think one advantage is its conceptual simplicity. It's literally just patch files; you can edit them by hand if desired. For people comfortable with or used to that, I can see the allure vs. the more mysterious operations occurring in "rebase --interactive" and such. Even quilt, the MQ progenitor, is still used today (at least on Debian).

Wasn't there an option (4): using 'qsave' and 'qpush --merge' to merge two MQ series with 3-way merge support? I don't think I've every really used it, though.

But overall, yeah Mercurial was playing catch-up to Git on that front for a while. Surely didn't help adoption.

[bvrmn]

MQ was a big revelation after working for 3 years with Git. Until I faced with StGit, it was much easier to use and fill more native especially with rebases.

[jorams]

> Originally, separate clones was the recommended way to do "topic branches" in Mercurial

This is still what the Guide on the Mercurial site mentions as the "basic workflow" for working on separate features. Named branches are considered "advanced", and bookmarks are an afterthought entirely.

About 10 years ago, after reading a lot about how hg was more intuitive than git, I decided to give it a try. I was already using git branches a lot, so this was definitely not a good first impression.

[EdiX]

People like to say that github is the reason git won the dvcs wars 10 years ago, but I think this is it. I think a lot of people's first impression of git back in the day was making a local mirror of their company's svn using git-svn. Without local branches this was a pointless exercise but with git you still got some benefit even without the remote being a git repository.

[jabl]

Back in the day I was doing some GCC development while upstream was still using SVN. At that time there was both Hg and Git mirrors, and while the GCC repo isn't that huge in the grand scheme of things, it's big enough that the "standard" hg workflow of having a separate checked out tree for every local branch you're working on was definitely painful. While I had been using hg for some personal projects, this was really the killer feature that drove me to git.

[interroboink]

> This is still what the Guide on the Mercurial site mentions as the "basic workflow" ...

I imagine you're referring to the "hg book"[1] ?

It irks me that that site hasn't been updated since ~2009, and there doesn't seem to be anything equivalent for "modern" Mercurial. Alas.

EDIT: oh, looks like there is a somewhat newer version (~2015?): https://book.mercurial-scm.org/read/part-getting-started.htm...

[1] http://hgbook.red-bean.com/

[jorams]

> I imagine you're referring to the "hg book"[1] ?

No, I mean when you go to the site and click the second item in the menu, Guide[1].

[1]: https://mercurial-scm.org/guide

[naasking]

Separate clones are basically exactly like forks on GitHub, which is pretty standard these days. Seems they were ahead of the curve (again).

[dzaima]

You don't make multiple forks of a project if you want to PR multiple separate changes though (github doesn't even allow it). And, on top of that, last I heard, forks in github are actually implemented as git branches. :)

[jjav]

> Aside: I prefer Mercurial myself, and I hope to keep using it for personal projects until I die (:

Same here. It is one of the minor tragedies that git won the popularity contest when mercurial is so much more pleasant.