I kind of killed Mercurial at Mozilla

I liked bzr because it had simple to understand “versions” I could abuse to use like a single source of truth. Git requires manually applying tags to imitate it.

maybe. at least on windows TortoiseHg was far superior to TortoiseGit.

just to be clear, i have worked with both hg and git, and can get along with either, but i do prefer hg.

have also written several foss tools - for example csvfix.

My understanding with the Mercurial stuff at Google is it was done that way because Mercurial defines a wire protocol, while Git does not (it expects a filesystem). So when fig was put together, they simply couldn't use git for the intended workflow, because it needed to be able to front-facade the existing CitC/Piper repository.

Prior to that, we used to use 'git5' which was kind of git bolted on in front of Piper, and it worked, but it was a little wonky with explicit import and export steps.

I tried to use fig a little before I left, and I can't say I was entirely blown away. I used to like Mercurial a decade and a half ago, and learned it before git... but it felt very foreign to me now.

FWIW I had stuff on Bitbucket from the Before Atlassian times, in Hg repos. And while I had let it bitrot a bit (too complicated to work on open source stuff with my employer at the time), once they dropped Mercurial support I saw no point in moving it to git and keeping it there so I just pulled it off and move it to github.

I'm sure I'm not the only one. The compelling story about Bitbucket for me was Mercurial.

Plus Atlassian is kind of just an awful company.

> 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.