---
title: "187 Commits to Fix Four Bugs"
canonical: https://dxdev.com/blog/2026-04-01_four-hotfixes-187-commits/
datePublished: 2026-04-01
---
On April 1, 2026, I had four tickets on the board.

A database tooling gap: dev-copy provisioning was missing a step that mattered in a specific edge case. A banner on tournament landing pages that kept disappearing for mobile visitors. A visitor-side bug on bracket views, the kind a player might hit once and blame on their phone. A game-schedule delete that silently failed under certain conditions. None of these was a crisis. Normal customer-fix posture: four issues, work through them, close each one.

By end of day I had authored 187 commits across eleven repos.

I had been telling myself the eleven clones bought me enough safety to justify their upkeep. The tally made that tradeoff harder to defend.

## why there are eleven repos

The production app runs on an old ASP Classic codebase. When I bought the business I inherited one repo. Then, as I started running parallel Claude sessions to accelerate development, 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. A fleet of long-lived git clones solved that by giving each session its own isolated working directory. 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 from which hotfixes tag and releases flow.

On paper that topology made sense. In practice, every bug fix I wrote had to propagate across the entire surface.

## the arithmetic of a propagation tax

Four fixes sounds modest. The bracket visitor bug alone touched a handful of ASP files. The change was maybe 40 lines. But fixing it once in the mainline was not the same as fixing it everywhere it needed to land.

In this setup, the hotfix flow involved a feature branch, the mainline release path, and reconciliation across the numbered clones so active working directories did not become stale. The reference archive had its own merge path. Merge commits compounded as that work moved through the topology.

Four fixes multiplied by the clone and merge paths, plus tag and bookkeeping commits, produced the 187 total. The count was not a measure of feature complexity; it was evidence of how many synchronization points the topology imposed.

## where the cost hides

No single commit in that day looked expensive. `git log --oneline` on any one repo would have read like a normal Tuesday. The cost only appeared at the level of the full operation, across all eleven, at the end of day.

That is the structural problem with per-fix topology taxes. They are invisible at the point of decision. When I scoped the bracket visitor bug I thought: small fix, maybe an hour. That estimate was accurate for the fix itself. It did not include the eleven-fold replication, the merge coordination across clones, or the verification pass I needed to run on the banner disappearance fix across four working copies before I could be confident the surfaces were consistent.

The number that matters is not how long a fix takes in isolation. It is how many times you have to apply it.

## what the safety net had become

I am not dismissing how I got here. The parallel agent sessions genuinely accelerated throughput on the development side. Running Claude against one clone while another session worked against a different one let me move faster on individual problems. That tradeoff made sense for a period.

What I had not done was stop and recount what the eleven clones were still buying by April 2026. When I set up the numbered copies, the isolation was the product. Each clone had supported an active branch, a session in flight, or a separate comparison point. By the time I shipped those four fixes, much of that load was gone. I was spending more effort keeping eleven trees synchronized than I was saving from the parallelism. The topology had not rotted exactly, but 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. These architectural cleanups tend to wait until the cost of waiting shows up as a single number you cannot argue with.

That number was 187.

In this setup, a normal bug-fix day producing hundreds of commits was a signal to reassess the release architecture, not simply work faster.

## Related

- [Env Drift Was the Real Bug](2026-03-28_env-drift-migration-tax): the companion lesson that long-lived clone fleets add migration and documentation work beyond the code change
- [Six Production Releases in One Day: Anatomy of a Hotfix Train](six-production-releases-before-lunch-hotfix-train): how small tags made rollback scope easier to reason about within a different release topology