The 24 Hours That Broke My GitHub

Yesterday, I made a decision that cost me an entire day of visibility on GitHub. This is the detailed breakdown of what happened, why it happened, and the technical mechanics behind it — with Mermaid diagrams so you can see exactly what went wrong.


Act I: The Bad Advice

I was doing a “GitHub audit” for job hunting. The goal: make my GitHub profile look clean for Singapore cybersecurity hiring managers.

An AI assistant (yes, I got bad advice from another AI — the irony is not lost on me) gave me this table:

Repository Called It Actual Status
bitcoin “Fork, no contribution” Not a fork — standalone repo
bitcoin-wiki “Academic, irrelevant” Not a fork — standalone repo
frontend “Fork, abandoned” Not a fork — standalone repo
hermes-agent “Fork, not your code” Not a fork — standalone repo
headhunter-agent “Fork, AI agent” Not a fork — standalone repo

Every single one was labeled “fork.” Not one was actually a fork.

The advice: make all 12 private. “Clean signal: 3–5 relevant projects.” “Noise: forks, tutorials, abandoned experiments.”

I said yes.


Act II: The Execution

for r in bitcoin bitcoin-wiki frontend hermes-agent headhunter-agent; do
  gh repo edit nurazhardotcom/$r --visibility private \
    --accept-visibility-change-consequences
done

One by one, 12 repos went dark.


Act III: The Reversal

This morning, I realized the advice was wrong. I ran:

for r in bitcoin bitcoin-wiki frontend hermes-agent headhunter-agent; do
  gh repo edit nurazhardotcom/$r --visibility public \
    --accept-visibility-change-consequences
done

All 21 repos are now public again. But the story doesn’t end there.


The Technical Deep Dive

What gh repo edit --visibility Actually Does

Architecture Diagram

The Fork Network Problem

Here’s the critical thing: if a repo IS a real fork, flipping it private severs the parent-child relationship in GitHub’s fork network. Flipping it back to public does NOT restore that connection.

Architecture Diagram

But Mine Weren’t Forks!

Here’s the twist: my repos were never forks to begin with.

Architecture Diagram

I verified this via GitHub’s own API:

gh api repos/nurazhardotcom/bitcoin --jq '{fork: .fork, parent: .parent.full_name}'
# {"fork": false, "parent": null}

Every single repo returned fork: false. The “fork network” problem was irrelevant because there was no fork network to begin with.


The Timeline

Architecture Diagram

What I Learned

1. Verify Before You Act

One gh api call would have prevented this:

gh api repos/nurazhardotcom/$repo --jq '.fork'

I didn’t run it. I took the AI’s word for it. That was the root cause.

2. Public Repos Don’t Hurt Your Resume

The advice said “21 public repos = noise.” That’s not how hiring works. Hiring managers look at: - What you built (not how many repos) - Code quality (not repo count) - Relevant projects (not whether you have irrelevant ones)

Having 21 repos with 4 pinned is not “noise.” It’s a portfolio.

3. --accept-visibility-change-consequences Is a Warning, Not a Formality

GitHub makes you add this flag for a reason. It’s not just “I accept.” It’s “I understand this might break things.” I clicked through without reading.

4. Visibility Changes Are (Mostly) Reversible — But Not Free

Architecture Diagram

For standalone repos (like mine), the flip is fully reversible — no permanent damage. But for real forks, the fork network break is permanent even after flipping back.

5. AI Advice Is Not Gospel

I got this advice from another AI tool. It was confident, detailed, and factually wrong. The lesson: always verify factual claims before acting on them, especially when the action is hard to undo.


The Current State

All 21 repos are PUBLIC and staying that way:

$ gh repo list nurazhardotcom --limit 25 --json name,visibility --jq '.[] | "\(.visibility)\t\(.name)"'

PUBLIC  nurazhar.com
PUBLIC  hermes-agent
PUBLIC  sol-de-tracker
PUBLIC  nurazhardotcom
PUBLIC  lagu-lagu
PUBLIC  frontend
PUBLIC  bsv-clj
PUBLIC  aur-audit
PUBLIC  bitcoin-wiki
PUBLIC  headhunter-agent
PUBLIC  bitcoin
PUBLIC  lithan_smartshop
PUBLIC  lithan_assignments
PUBLIC  lithan-dev-sandbox

Key Takeaway

Never change repo visibility based on unverified advice.

One API call. Five seconds. Would have saved 24 hours.


Written at 2:00 AM because I couldn’t sleep thinking about this. The Mermaid diagrams render on GitHub natively — if you’re reading this in a viewer that doesn’t support Mermaid, the source is in the blog repo.