Three Dollar Quill

In this post:

• I namedrop a bunch of VCSs, but somehow not all of the ones I've heard of.
• I describe two non-Git tools for interacting with Git repositories, and try to list the pros and cons of each.

I've used a few different version control systems over the years, like Bazaar, possibly Fossil (I don't actually remember), probably not Darcs but I'm not sure, SVN for I know not what reason, mostly Mercurial, and a little bit of Git.

All in all, this doesn't add up to much cross-cutting expertise. I'll sum up the stuff I remember quickly:

• I cannot remember anything about using Bazaar that differentiates it from Mercurial
• Mercurial has some rough edges that I've mostly learned to deal with; I mostly remember having a bad time untracking stuff I didn't want to commit
• Git is terrifying and confusing

However, it's also becoming more and more prominent; I kind of forget that software projects can be places besides GitHub, sometimes. Which is kind of a bad thing, but also a true thing. A truly bad thing.

So, what am I to do if I want to use GitHub, but not Git? Well, I've found two solutions so far. Neither one entirely satisfies.

For my own projects, I've been using Hg-Git. At work, I had been using Hg-Git, but I'm attempting to switch to Gitless, for reasons that will become clear later.

Hg-Git works on the principle of converting between Git and Mercurial repositories. In terms of workflow, all that's required compared to my normal usage habits is to ignore branches in favor of tags. There are some caveats here that make me reluctant to recommend it generally, though. In some ways, Hg-Git is a cobbled-together shim on top of a set of unstable interfaces, and speaking as the developer and maintainer of a cobbled-together shim on top of a set of unstable interfaces, I know maintaining those can be pretty thankless. Hg-Git has got to be even less pleasant to support than Divide and Cover, because some of the distribution networks for Mercurial seem to aggressively disappear old versions. Old versions that actually support the current release. The other issue I hit was that it was kind of confusing to figure out which way to invoke clone. What worked for me, I think, was to follow all of GitHub's instructions for setting up an ssh key, and clone git+ssh://git@github.com/username/some-repo.git Basically, if you like Mercurial, and you can install a working combination of Mercurial and Hg-Git, there's only one reason I'd recommend anything else. And that's if you're collaborating with people using Git-specific tooling.

At my job, we are developing Git-specific tooling, so I can't just throw it at a repository converted to Mercurial and expect anything useful to happen. To run our scripts, and later, potentially, our pre-commit hooks, I need to be working with actual Git repositories. Enter Gitless. Gitless is an attempt to give Git, the underlying revision history system, a different, better-designed interface than Git, the command-line tooling. I'd read the papers describing it months ago, and hadn't had a compelling reason to try it out before now. I've only been using it for a few days, so my impressions aren't fully formed, but I want this post done now, so that's the way it goes. As I understand the papers, Gitless is a proof-of-concept for some design principles: can these principles be applied to a notoriously complicated tool, and deliver equivalent functionality with a simpler interface? The paper lays out several criticisms of Git that Gitless is supposed to handle better. The thing that's confused me thus far about the reactions I've read to these criticisms is, I've seen people say that some of them don't apply to Mercurial, but I don't think I've seen anyone mention that some of them do. So, that was one of the things that pushed me away from trying out Gitless on my own. It's not that I think good design has to look like the current state of Mercurial, but I knew that Gitless wouldn't fit into what I was used to.

The direction of things at work changed the balance, though. If the tooling needs a Git repository, I have to give it a Git repository. And Gitless let me do that. As I said, I've only been using it a few days, so I haven't dug into the really advanced features. Point in its favor, though: all of the worst issues I had were down to getting confused between two similarly-named repositories, and resulted in no bad commits. There isn't much documentation, but I haven't really needed much more than there is, so I think that's good.

Gitless was also kind of tricky to install, in that there were many ways to try to install it, and some of them took a long time to not work. On Mac, I found my best bet was to install all of it via Homebrew. There are instructions for installing just the dependencies via Hombrew, but that had various issues, and it Just Worked when I installed the whole thing through Homebrew.

I wish I had some kind of snappy conclusion to this, something really satisfying, but all I've got is the truth of my lived experience. And the truth of my lived experience is, I like Hg-Git, but it's hard to set up and maintain a working install, and it looks like Gitless fulfills the stuff I need for work, but I don't actually know yet. I'll probably keep on using Hg-Git for my own stuff, and for work, we'll see how things work out.