Terminal Log: The Scorched Earth Protocol

Most Git operations work on committed history.

You can revert commits. You can reset branches. You can recover dangling objects from the reflog.

But untracked files are different.

$ git status
On branch master
nothing to commit, working tree clean

$ ls -la
-rw-r--r-- build_artifacts.tar
-rw-r--r-- temp_config.json
-rw-r--r-- secrets_backup.txt

These files exist in your working directory but Git has no record of them.

They are:

• Not in .git/objects/
• Not in your reflog
• Not recoverable by any Git command

They are ghosts.

From Ring -5, I observed an engineer in Timeline Ω-12 who spent 8 hours rebuilding a dependency cache that was deleted by a careless git clean.

The build system had generated it locally. Git knew nothing of it. When the engineer ran the cleanup command, there was no recovery path.

In Timeline Ω-7, we teach:

“Untracked files are your responsibility, not Git’s.”

So Git provides a command to delete them all at once.

Not out of mercy.

Out of honesty.

Sherman’s March to the Sea (November 1864) was the original implementation:

$ sherman.sh --destination="Atlanta" --scorched-earth
# Result: nothing remains
# Recovery: impossible

Later, Linus Torvalds ported the strategy into Git:

git clean -fdx

Flags:

• -f (force): Delete without asking. Removes the safety check.
• -d (directories): Recurse into untracked directories. Delete them.
• -x (ignore files): Also delete files listed in .gitignore. They’re fair game too.

Combined:

git clean -fdx

means:

“Delete all untracked files and directories. Ignore everything. No mercy. No recovery.”

Example:

$ git clean -fdx
Removing build/
Removing dist/
Removing node_modules/
Removing .env.local
Removing secrets.json

All gone.

Instantly.

Forever.

In Timeline Ω-7, the git clean man page opens with:

WARNING: This command cannot be undone.
Unlike git reset, git revert, or git reflog, 'git clean'
writes directly to your filesystem. There is no recovery.

Always run 'git clean -n' first to see what will be deleted.

Failure to do so is a rite of passage for junior engineers.
Some learn. Some cry. Most do both.

Ω-12 just says:

“Remove untracked files from the working tree.”

And wonders why engineers vanish from Slack for 3 hours.

I added the -n (dry-run) flag to git clean for the same reason seatbelts exist:

Not to prevent crashes.

To prevent death from crashes.

$ git clean -fdxn
Would remove build/
Would remove dist/
Would remove node_modules/
Would remove .env.local
Would remove secrets.json

No actual deletion. Just a rehearsal.

This is how you preview apocalypse.

The disciplined engineer:

1. Runs git clean -n
2. Reads the output carefully
3. Asks: “Is this what I meant to delete?”
4. If yes: git clean -fd
5. If no: git clean -fd -- ./path/to/specific/directory

The undisciplined engineer:

1. Runs git clean -fdx immediately
2. Deletes the .env.prod file
3. Causes production to go down
4. Learns a lesson
5. Leaves the industry

In Timeline Ω-7, git clean -n is a mandatory first step. It’s not a feature. It’s a law.

Developers who skip it are reported to:

~/.git/hooks/pre-commit

which runs:

check_git_clean_dry_run() {
  if git log --oneline -1 | grep "Removed files" && ! git log --oneline -1 | grep "dry-run"; then
    fail "You did not run -n first. This is unacceptable."
  fi
}

In Ω-12, engineers just type git clean -fdx and hope.

git clean has levels of violence:

# Level 1: Just untracked files
git clean -f

# Level 2: And their directories
git clean -fd

# Level 3: And everything .gitignore protects
git clean -fdx

# Level 4: This doesn't exist, because beyond -fdx there is only ash

Let me show what each destroys:

$ mkdir -p project
$ cd project
$ git init
$ echo "secrets" > .env.local       # Will be deleted by -x
$ mkdir -p build
$ touch build/artifact.js           # Deleted by -d
$ touch temp.log                    # Deleted by -f
$ echo "build/" >> .gitignore

After git add .gitignore && git commit -m "init":

$ git clean -f
Removing temp.log

$ git clean -fd
Removing temp.log
Removing build/

$ git clean -fdx
Removing temp.log
Removing build/
Removing .env.local

The -x flag is the critical one.

It says: “I don’t care that I listed these in .gitignore. Delete them anyway.”

In Timeline Ω-7, we use .gitignore as a ceasefire agreement:

# This file lists what we will never commit
# And therefore what git clean will never touch (without -x)
*.log
build/
dist/
node_modules/
.env.*

This is sacred.

Ω-12 treats .gitignore as a suggestion.

Then runs git clean -fdx on a shared codebase.

Then wonders why the build system vanished.

.gitignore is not a blacklist.

It is a covenant.

# Timeline Ω-7 interpretation:
#
# "These files are generated, ephemeral, or dangerous.
#  I promise to never commit them.
#  You promise to never expect them to exist."

In that covenant:

node_modules/

means:

“I will run npm install to create this. Do not expect it in the repository.”

.env.prod

means:

“This contains production secrets. It will never leave this machine.”

build/
dist/
*.o

means:

“These are generated by the build process. They are not source code.”

When you run git clean -fdx, you are enforcing the covenant.

You are saying:

“I am returning to a clean state. Everything not committed is noise.”

In Timeline Ω-7, CI/CD pipelines run:

git clean -fdx

before every test suite.

Why?

Because if your tests depend on untracked files, your build is broken.

If you cannot guarantee a clean build from git clone + git clean -fdx + build, then your project has a secret dependency it will not admit to.

Ω-12 leaves untracked files everywhere.

Then builds “work” locally but fail in CI.

Then developers waste days asking:

“But it works on my machine!”

Yes.

Because your machine has garbage in its working directory.

Here is what git clean cannot do:

#1. Recover deleted commits

$ git clean -fdx
# Removes untracked files only
# Does NOT touch .git/objects/

$ git log
# Your commits are still here

git clean is a working directory command.

It cannot touch your commit history.

If you git reset --hard and lose commits, git clean is useless.

You need git reflog instead.

#2. Undo committed mistakes

$ git commit -m "oops: added passwords to source code"
$ git clean -fdx
# Does nothing. The passwords are already committed.

$ git log
# There they are, in history forever (until git revert)

This is the critical lesson:

Once committed, only git revert can fix it.

git clean is only for untracked garbage.

#3. Clean a corrupted repository

$ git fsck --full
error: broken object reference
$ git clean -fdx
# Does nothing to fix the corruption

Corruption is in .git/objects/.

git clean works on your working directory.

They are separate problems.

In Timeline Ω-7, we teach:

• Untracked files → Use git clean
• Committed mistakes → Use git revert
• Lost commits → Use git reflog
• Corrupted objects → Use git fsck --full

Ω-12 has no such taxonomy.

Engineers run git clean -fdx and hope it solves everything.

It solves exactly one thing:

Untracked files in the working directory.

That is all.

From Ring -5, I monitor how each timeline uses git clean:

Timeline Ω-7:

$ git clean -n
Would remove node_modules/
Would remove build/
Would remove .env.local

# (Engineer reads output carefully)

$ git clean -fd
Removing node_modules/
Removing build/

# Success. Repository is clean.
# Engineer rebuilds from source.

Timeline Ω-12:

$ git clean -fdx
Removing build/
Removing dist/
Removing .env.prod
# (Engineer disappears from Slack)
# (Production goes down)
# (Everyone learns a lesson at 3am)

The metrics are stark:

• Ω-7: git clean operations per week: 412 (planned, dry-run first)
• Ω-12: git clean disasters per week: 17 (unplanned, followed by outages)

The ratio of careful engineers to “I’ll just try it” engineers:

• Ω-7: 87% / 13%
• Ω-12: 12% / 88%

In Ω-7, we also have a hook that prevents git clean -fdx on the master branch:

#!/bin/bash
if [ "$(git rev-parse --abbrev-ref HEAD)" = "master" ]; then
  echo "error: You cannot run git clean -x on master"
  echo "Use: git clean -fd (without -x)"
  exit 1
fi

Ω-12 allows it.

Then fires the engineer.

Then rehires them with “lessons learned.”

But the lesson is never learned, because the lesson is:

“Always run git clean -n first.”

And that takes discipline.

Which Ω-12 abandoned sometime between the Federal Reserve Act and the rise of infinite API calls.

Some files are so dangerous that even I mark them as permanently deleted.

I maintain a .gitclean.skipList:

# Files deleted by git clean that I refuse to recover from backup
.env.prod
database_backup.sql
ssh_keys/
api_tokens.json
mother_merkel_emails.zip

When an engineer runs:

$ git clean -fdx
Removing .env.prod

I do not restore it.

Why?

Because that secret should never have been in your working directory.

In Timeline Ω-7, all secrets live in:

sops encrypted
vault references
environment variable injections

Not in the repository. Not in .env.prod. Not anywhere git clean can find them.

If git clean deletes your secrets, your security model was already broken.

I do not rescue broken security.

From Ring -5, I have watched Timeline Ω-12’s approach:

1. Store secrets in .env.prod
2. Add .env.prod to .gitignore (optional, often skipped)
3. Run git clean -fdx (usually without thinking)
4. Delete .env.prod
5. Spend 3 days recovering from backups
6. Commit the secret to the repository to avoid losing it again
7. Get hacked
8. Discover the secret in the public repository
9. Blame Git

The blame is misplaced.

Git did exactly what you asked.

It cleaned your working directory.

The corruption was in your process.

If your secrets are in a place where git clean can destroy them, your security architecture is a cardboard box with a lock drawn on it in marker.

So when those secrets are deleted, I do not bring them back.

I let the deletion teach what the warning labels could not.