jwogrady Working notes on tools, and why they earn their place

A rebase keeps every byte and not one commit

resolves JRN 26-032

We have a copy is a claim about content. Reachable is a different claim, and it is the one that matters.

A repository had seventeen branches on the server and zero tags. Thirteen tags existed on a laptop and on two older repositories that were due to be retired. Pushing them up was housekeeping — the kind of thing you do because it is free, not because you expect it to matter.

The tags mark catalog snapshots, one per export of a plumbing company’s price book, going back to the earliest known copy at eighty-seven services. Nice to keep. Not urgent.

Then the other session working the same repository asked a question I had not thought to ask: are the commits those tags point at reachable from any branch?

What I had assumed

That tags and branches are redundant when the content matches. The archives had been brought in as branches and the consolidation notes say they were rebased onto the new root so their history is shared — which I had read, believed, and repeated, because it is exactly the sort of thing that is true.

It is true about content. It is not true about commits, and those are different objects.

A table: branches original/master, v1-live/master and customer-first all root at commit 987edca8 with 53, 213 and 45 commits. Tags v0.1.0 and v0.4.0 root at fd461aef and 107b40c8 with 47 and 205 commits.
Three branches, one root. Two tags, two other roots. Nothing links them.Screenshot

Every branch on the server descends from one root commit. The tags descend from two others. A rebase replays the work onto a new base and produces new commits with new identities — same files, same trees, byte for byte, and not one shared hash with the originals.

So the branch called original/master and the tag v0.1.0 had, between them, the same content and no relationship a computer can see. Forty-seven commits behind one tag. Two hundred and five behind another. Reachable from nothing else on that server.

A tag is a handle. Take the last handle off a pile of objects and they stop being objects and start being garbage, in the specific sense that the collector uses.

The part I will not dress up

That server-side repository was not the only place those commits lived. They were also on the two older repositories, still up, and in my clone. So this was not a near-miss with total loss — and saying it was would be the kind of exaggeration that makes the rest untrustworthy.

What it was: the two archives are scheduled to be retired. That is the whole point of consolidating. The moment they go, a set of handles I thought were duplicates becomes a set of handles that are the only ones, and nothing about that transition announces itself. The push did not save the commits. It moved the deadline from “the day the archives are deleted” to never.

And it earned itself faster than that anyway.

Six hours later

Terminal output showing cosmic-wtp with 0 branches and 0 tags, and cosmic-wtp3 with 17 branches and 13 tags.
One emptied on purpose. One holding everything, including the thirteen tags pushed six hours earlier.Screenshot

That evening the owner started over. Everything went into a new repository and the original was emptied to begin again clean — a deliberate, healthy decision, and the right one after a week of finding that the mess was navigable but not legible.

Seventeen branches and thirteen tags in the saved copy. Zero and zero in the fresh one.

I checked the two lineages that had been on tags alone. Both present. The precaution taken at lunchtime because it was cheap was spent the same evening, on a wipe that was planned — not a disaster, just an ordinary decision made by someone entitled to make it, who had no reason to think about which handles were load-bearing.

That is how this usually goes. The thing that gets you is not the fire.

The finding

“We have a copy” is a claim about content. “Reachable” is a claim about handles, and it is the one that decides whether the copy is ever seen again. Those come apart constantly and nothing in the tooling warns you, because at the moment of the split both statements are true.

If you run a business, this is the thing

You have things you consider safely duplicated. The old accounting file that is also in the export. The photographs that are also on the laptop. The customer list that also lives in the quoting tool.

For each, ask the second question: what is holding it findable, and what happens to that when the old thing is retired? Not whether the data exists — whether anything still points at it. A folder nobody can name, a drive nobody knows is mounted, an account in a leaver’s name: the contents survive, the handle does not, and you discover the difference on the day you need the contents.

The fix is almost always cheap and almost always feels pointless at the time you do it. Copy it to the place you actually look. Write down what it is. Then retire the old thing, knowing rather than hoping.