I Didn’t Break Git. Git Broke My Brain.
This Is What Happens When You Assume Tools Share Context
- Git wasn’t broken. My editor didn’t inherit my SSH state.
- SSH works until you assume tools share context by default.
- Fixing it meant validating state, not adding new tools.
- If you don’t know which layer you’re in, error messages will lie to you.
I sat down with a simple goal:
“Document my existing server so Future Me can rebuild it without panic.”
No rebuild.
No automation.
No clever abstractions.
Just:
- Ghost
- Docker
- Caddy
- A notebook repo in GitLab
What followed was a multi-hour descent into the uncanny valley between “this should work” and “nothing is actually broken.”
The Setup (That Already Worked)
Before anything went sideways, this was the reality:
- DigitalOcean droplet
- Ubuntu
- Ghost + MariaDB via Docker
- Caddy doing TLS
- Everything live and stable
I wasn’t trying to change the system. I was trying to describe it.
That distinction matters.
Where Things Went Off the Rails
The moment I tried to involve VS Code + GitLab, reality fractured.
From my perspective:
- Git had worked with SSH keys
- WSL had worked
- VS Code should have been a UI on top of that
From the computer’s perspective:
- VS Code terminals ≠ login shells
- ssh-agent may or may not exist
- environment variables are vibes
- authentication is contextual
So I got errors like:
Permission denied (publickey)While simultaneously being able to run:
ssh -T git@gitlab.com
…and getting a warm welcome message.
Both things were true.
That’s the worst part.
The Actual Problem (In Plain English)
Nothing was wrong with:
- my SSH key
- my GitLab account
- my repository
- my server
The problem was process inheritance.
VS Code was running Git in an environment that did not have access to ssh-agent, even though my shell did.
That meant:
- Git worked in one place
- Git failed in another
- Error messages lied by omission
Once you know that, everything snaps into focus.
Before you know it, you feel insane.
The Fix Was Boring (Which Is the Point)
The “fix” was not some deep Git magic.
It was:
- starting
ssh-agent - loading the key
- making sure VS Code restarted so it inherited the environment
- validating state explicitly instead of trusting tools
After that?
Everything worked.
No drama.
No new tools.
No redesign.
The Bigger Lesson
This wasn’t about GitLab.
It wasn’t about WSL.
It wasn’t even about VS Code.
It was about assuming that tools share context when they don’t.
Modern dev tooling stacks are layered like this:
- The OS
- The shell
- The agent
- The editor
- The editor’s Git wrapper
- The Git provider
When something breaks, it’s almost never “Git is broken.”
It’s:
“Which layer doesn’t see the thing I think it sees?”
Until you answer that, you’re shadowboxing.
Why I Still Documented Everything
Even after the frustration, I did the thing I set out to do:
- Captured live config as-is
- Mirrored
/srvin a repo - Documented rebuild steps
- Backed up volumes explicitly
Not because it was fun.
Because future outages don’t care how tired you were today.
Closing Thought
There’s a special kind of exhaustion that comes from:
“I know this works.
I just can’t prove it to the computer.”
If you’ve been there: you’re not bad at this.
You’re just operating in a world where state matters more than intention.
And sometimes the most professional move is:
- slow down
- verify
- write it down
- and walk away when it finally works
Future You will be grateful.
