The Road Now Taken: Why AI Moved Me from Mercurial to Git

In 2024, I wrote an article called Mercurial: The Road Less Traveled. In it, I borrowed from Robert Frost to explain my choice of Mercurial over Git, a choice that "has made all the difference," both good and bad.

Frost's traveler keeps the first road for another day, then admits:

"Yet knowing how way leads on to way,
I doubted if I should ever come back."

Well, I came back.

I've finally made the move from Mercurial to Git and GitHub for version control. And AI is the reason.

AI both forced me to make the move and made the move much easier.

Yet again, it seems that AI is to me what alcohol is to Homer Simpson, "The cause of, and solution to, all of life's problems."

Why I Chose Mercurial in the First Place

If you search through the Version Control tag here on No Longer Set, you'll find several articles about Mercurial. The gist of it is this.

When I chose between Mercurial and Git, they had basically split market share evenly. And Mercurial was a much better fit on Windows. TortoiseHg had a better user interface versus the mishmash of command lines that you needed to remember for Git, and there was no good user interface experience on Windows using Git at the time.

That part hasn't really changed over the years.

The main reason I went with Mercurial over Git, though, was a difference in philosophy. Mercurial did not allow you to rewrite history by default, so it was safer (by default).

It did mean that anything you committed was sort of there forever. There was no real undo button. But that fit into how I'm used to thinking about things, especially writing software for banks and other entities where you can't just be going in and making changes to records. To me, a permanent, immutable audit trail was a feature, not a bug.

I really liked that part of Mercurial, especially because I had read some horror stories about how certain commands in Git could completely destroy your local repository and even your remote repositories (which act as backups for me).

In my mind, the whole point of version control was to increase safety and security. A version control system that allowed you to wreck it didn't make any sense to me.

How AI Forced the Move

In my 2024 article, nearly every item on the "bad" side of the ledger came back to one thing: Mercurial is the less popular choice. GitHub has no real equivalent in the Mercurial world, and integrations for Git are everywhere while integrations for Mercurial barely exist.

For years, I could live with that. AI changed the math.

Because of the way that I've been using AI, I now have a lot of integrations between Linear, GitHub, Git, and Claude Code running in VS Code. All of these things work together to increase the safety and security of agentic AI-driven workflows. And all of them assume Git.

The network effects of going with Git and GitHub now far exceed the benefits I got from using Mercurial.

How AI Made the Move Easier

Knowing I needed to switch and being willing to switch, though, are different things.

Two things finally got me over the hump:

1. No More Cryptic Command Lines

With AI, I no longer have to learn all of the cryptic command-line arguments. I simply installed the gh command-line interface for GitHub, and now I tell Claude Code what I want it to do with Git and GitHub, and it simply does it.

The biggest practical objection I had to Git, the one that TortoiseHg solved for me all those years ago, just went away.

2. Safety Through Guardrails

The safety part was harder. That was a philosophical objection, not a practical one.

One of the first safeguards we put in place was the idea that you cannot "force push" changes to main on GitHub. We created a ruleset that blocks that entirely. The only way to get changes into the main branch is by approving a pull request and then merging it.

That one ruleset prevents a lot of the worst kinds of damage that can be done. I felt a lot more comfortable with that protection in place.

In other words, Git still allows you to rewrite history. But I can now make sure it doesn't happen accidentally where it can do irreversible damage.

The Unexpected Upside: Squash Merge

The other thing I really liked about Git was something I didn't expect: the squash merge workflow.

While I'm working on a feature, I can put in a lot of detailed commits as part of a work in progress, all on a separate feature branch. Once the feature is completely ready, I open a pull request and squash merge it into the main branch.

A squash merge takes all the individual changes from the various commits that make up the pull request and compresses them into a single diff that gets added to main. When you look back at the history of the main branch, you don't see all the missteps and work-in-progress stuff. You only see the clean changes. The result is a very high signal-to-noise ratio.

I have a main branch that is very clean, but I keep the granular detail of how I got there in the GitHub pull request history.

There's more to this workflow than I can do justice to here, including why I didn't want to lose that granular detail and the trade-offs involved. I'll cover that in an upcoming article.

Final Thoughts

I've never regretted my decision to use Mercurial over Git.

But the downsides of that choice grew steadily over time. AI was simply the anvil that broke the camel's back.

The network effects became impossible to ignore, and the two biggest reasons I avoided Git–the cryptic command line and the risk of wrecking my repository–are no longer barriers.

It turns out I could come back after all.

AI attributions: this post started with a stream of consciousness spoken into Wispr Flow, transcribed to text, and fed to Opus 5.5 with instructions to keep my phrasing but make the whole thing coherent. It then went through several iterations of cleanup and human rewrites of a few entire paragraphs. The result is a collaboration between man and machine with the goal of bringing to bear the best of both.