---
title: "187 Commits Across Eleven Repos From Four Routine Customer Tickets"
canonical: https://dxdev.com/blog/four-hotfixes-187-commits/
datePublished: 2026-04-01
---
On April 1, 2026, four tickets sat on the board. By the end of the day, routine customer fixes had produced 187 commits across eleven repos.

The tickets were a database tooling gap, where dev-copy provisioning was missing a step that mattered in one edge case. A banner on event landing pages that kept disappearing for mobile visitors. A visitor-side bug on a public-facing view, the kind a visitor hits once and blames on their phone. And a schedule delete that silently failed under certain conditions. None of them was a crisis. It was the normal customer-fix posture: work through them, close each one.

We had been telling ourselves the eleven clones bought enough safety to justify their upkeep. That tally made the tradeoff harder to defend.

## Why there are eleven repos

The production app runs on a legacy application codebase. Originally there was one repo. Then we started running parallel Claude sessions to speed up development, and a single working directory became a chokepoint. Two agent instances editing the same file at the same time produce merge conflicts at exactly the wrong moment.

So we built a [fleet of long-lived git clones](/blog/branch-graveyard-automated-cleanup/), one isolated working directory per session. Each is a full clone of the mainline. An earlier freeze point is kept separately for reference and comparison. The mainline is the canonical codebase, where hotfixes tag and releases flow from.

On paper the topology made sense. In practice, every fix we wrote had to propagate across the whole surface.

## What one fix actually costs

The visitor-side bug alone touched a handful of files in the legacy application. The change was maybe 40 lines. Small. But fixing it once in the mainline was a different job from landing it everywhere it needed to be.

The hotfix flow ran through a feature branch, the mainline release path, and reconciliation across the numbered clones so the active working directories didn't go stale. The reference archive had its own merge path. Merge commits piled up as each fix moved through the topology.

Four fixes, multiplied by the clone and merge paths, plus tag and bookkeeping commits, gave us 187. That count was not a measure of work done. It measured how many synchronization points the topology imposed.

## Why nobody saw it coming

No single commit that day looked expensive. `git log --oneline` on any one repo would have read like a normal day. The cost only showed up when we added up the whole operation across all eleven at the end.

That is what makes a per-fix topology tax so hard to see. It is invisible at the point of decision. When we scoped the visitor-side bug, we thought: small fix, maybe an hour. The estimate was accurate for the fix itself. It left out the eleven-fold replication, the merge coordination across clones, and the verification pass on the banner fix across four working copies, which we needed before we could trust that the surfaces were consistent.

The number that matters is how many times you have to apply a fix.

## What the safety net had become

The parallel agent sessions did speed up development. Running Claude against one clone while another session worked on a different one let us move faster on individual problems, and for a period that tradeoff made sense.

What we hadn't done was recount what the eleven clones were still buying by April 2026. When we set up the numbered copies, the isolation was the whole point. Each clone supported an active branch, a session in flight, or a separate comparison point. By the time we shipped those four fixes, much of that load was gone. We were spending more effort keeping eleven trees synchronized than we saved from the parallelism. The topology hadn't rotted exactly. It had stopped paying for itself.

Collapsing the hotfix path down to one canonical codebase and one release flow is on the list. It has been on the list for a while. These cleanups tend to wait until the cost of waiting shows up as a single number you can't argue with.

That number was 187.