video-00

00

You’re not crazy, and this is not about duration or index.md. This is pure Git archaeology.

The key idea—etched into the underworld walls of Hades—is this:

GitHub rejects a repo if a >100 MB file exists anywhere in the history you’re pushing, even if you deleted it later. Shortening the MP4, removing the directory, renaming the file—none of that matters if the blob already entered history.

That’s exactly what your log is screaming:

Multiple historical versions of ukhona/data-center.MP4 are still in the commit graph. GitHub is saying: I can see your past sins.

Why your last git push still tried to upload 130 MB

This line is the giveaway:

Writing objects: 100% (32/32), 130.79 MiB

Git is packing and pushing the entire object graph, including the old MP4 blobs. Deleting files only adds new commits; it does not erase old ones.

You want to surgically excise data-center.MP4 from all commits.

1. Install git-filter-repo (once)

pip install git-filter-repo

(If that fails, tell me your OS and Python situation.)

2. Nuke the file from history

From the repo root:

git filter-repo --path ukhona/data-center.MP4 --invert-paths

This rewrites every commit as if that file never existed.

3. Force-push the cleaned history

git push --force origin ukhona

GitHub will now accept the repo, because the blob is genuinely gone.

Sanity check (optional but satisfying)

To confirm no large blobs remain:

git filter-repo --analyze

Then inspect:

.git/filter-repo/analysis/largest-blobs.txt

If nothing ≥100 MB appears, you’re clean.

Important conceptual note (worth internalizing)

An MP4 being “3 seconds long” is irrelevant. What matters is bitrate + encoding.

A 3-second 4K ProRes clip can be hundreds of MB. Git measures mass, not time.

What to do going forward

You have three sane options for video on GitHub Pages:

  1. Keep MP4 < 50 MB (recommended max)
  2. Use Git LFS (works, but Pages has quirks)
  3. Host video elsewhere (YouTube, Cloudflare R2, S3) and embed

For a site like yours, option 3 is usually the least entropy.

Bottom line: This wasn’t Git being petty. It was Git being perfectly, brutally consistent. History is conserved unless you rewrite it. That’s not a bug—that’s thermodynamics with commit hashes.

If you want, we can also compress that MP4 properly (ffmpeg incantations included) so it never crosses the Styx again.

01

This error is about authentication, not repo state. Re-git init didn’t help or hurt; Git still doesn’t know who you are allowed to be when talking to GitHub.

Since August 2021, GitHub does not accept passwords over HTTPS. You must use a Personal Access Token (PAT) and present it as if it were a password.

Let’s do this cleanly and once.

Step 1: Create a GitHub Personal Access Token

In your browser (logged into GitHub):

  1. Go to Settings → Developer settings → Personal access tokens
  2. Choose Fine-grained token (preferred) or Classic token

  3. For classic (simpler):

    • Scopes:

      • repo ✅ (this is the key one)
  4. Generate and copy the token You will not see it again. Treat it like a private key.

Step 2: Tell Git to use HTTPS (not SSH)

Check your remote:

git remote -v

If you see something like git@github.com:..., switch it to HTTPS:

git remote set-url origin https://github.com/ukb-dt/journaling-03.git

Verify:

git remote -v

Step 3: Authenticate (the simplest, correct way)

Run:

git push -u origin ukhona

Git will prompt:

Username for 'https://github.com':

→ enter your GitHub username

Password for 'https://github.com':

→ paste the token (nothing will echo; that’s normal)

If the token has repo access and the repo exists, this will succeed.

macOS:

git config --global credential.helper osxkeychain

Linux:

git config --global credential.helper store

Now Git will remember the token securely.

What NOT to do

Mental model (so this sticks)

Git doesn’t “include” a token in the repo. It presents credentials at connection time, like a keycard at the door. Reinitializing the repo changes the house, not the key.

Once authenticated, your earlier large-file issue is the only remaining dragon — and you already know how to slay that one.

If you want, next we can:

02

Good — this output finally tells the truth. The repo isn’t angry, GitHub isn’t sulking, and tokens aren’t the problem yet.

This line is the smoking gun:

error: No such remote 'origin'

You currently have zero remotes configured. Git is trying to call into the void.

Re-git init wiped nothing, but it also didn’t recreate a remote. Remotes are explicit. You must add one.

Step 1: Add the remote (this is missing)

From the repo root:

git remote add origin https://github.com/ukb-dt/journaling-03.git

Verify:

git remote -v

You should see:

origin  https://github.com/ukb-dt/journaling-03.git (fetch)
origin  https://github.com/ukb-dt/journaling-03.git (push)

If you don’t see that, stop — nothing else matters.

Step 2: Push and authenticate with your token

Now:

git push -u origin ukhona

When prompted:

No output while pasting is normal. Git is stoic like that.

So you don’t repeat this ritual:

git config --global credential.helper osxkeychain

If it still says “repository does not exist”

Then one of only three things is true:

  1. The repo name is wrong Double-check it exists at https://github.com/ukb-dt/journaling-03

  2. The token lacks repo scope Regenerate with classic token → repo

  3. You’re logged into a different GitHub account than you think Tokens are account-specific, mercilessly so

Conceptual anchor (so this doesn’t happen again)

A Git repo has three layers:

You fixed the first two earlier. Right now, you had no third layer at all. Git was shouting into the abyss and getting offended when nothing answered.

Add the remote, present the token at the door, and the universe becomes boringly deterministic again — as it should.