Back to Blog

Why I Didn't Delete the Old Laravel History, Just Moved It to a Branch

#git#migration#engineering
Why I Didn't Delete the Old Laravel History, Just Moved It to a Branch

This site used to be Laravel 13 + Postgres/Supabase + Docker, complete with a full admin panel and AI content generation. Now it’s fully static Astro, and none of that old code runs in production anymore. But I didn’t delete its history — I moved it to a separate branch, gookkis-web-laravel-old, and it’s still sitting there in the repo.

Why not just delete it? Because deleting history is an operation that’s easy to regret later, and the regret usually shows up after the fact, not in the moment when you’re thinking “I probably won’t need this again.” There were design decisions in the old app — how the admin panel was structured, how I used to generate AI content through a queue job — that I’ll never redeploy, but that are still worth having around as reference.

A concrete example: a few months after the migration, a client asked how I’d handled rate limiting for an API generation feature in that old Laravel app, because they were building something similar. I opened the branch, walked back through old commits, found the implementation in a few minutes, and sent them the relevant snippet. If I’d deleted that branch outright, I’d have had to rely on memory alone to explain logic I hadn’t touched in months — and memory of implementation detail like that is always blurrier than you’d expect.

Why not archive it somewhere else — a separate zip, another repo? Because keeping it as a branch in the same repo means it stays searchable and diffable anytime through the same git tooling I already use daily, without needing to remember where I stashed a backup or install anything extra to open it. git log on that branch is still real history — every commit, every commit message (some of them a little embarrassing) showing exactly what I was thinking at the time — not a snapshot squashed into one giant commit.

The trade-off I accept: the repo is a bit bigger for carrying two projects’ worth of history with completely different stacks — the .git folder is a few dozen MB heavier than it would be with just the Astro history. For a large team repo full of binary assets, that could be a real problem, and the usual advice is git filter-repo or a separate archive. But for a personal repo like this, that size difference is nothing next to the value of keeping the reference around if I ever need it — cloning this site is still instant on a normal connection.

One thing I do enforce: that branch is frozen. I never merge it back or rebase it against main, and no CI runs on it. It’s a read-only archive by convention — not technically protected on GitHub, just self-discipline about not touching it. If I need something from it, I copy the relevant snippet out manually rather than cherry-picking commits directly, so main’s history stays clean and linear.

Git doesn’t charge me for keeping the past. As long as it doesn’t get in the way of work on main, I’d rather keep it than regret deleting something that turned out to still be useful.