Ever opened a repository and seen a contribution from 2014 staring back at you? It’s eerie. You’re looking at code written when Flappy Bird was the biggest thing on the internet and the industry was still arguing about whether Docker was a fad.
10 year old commits aren't just digital fossils. They’re becoming a weirdly frequent occurrence in modern dev workflows, often for reasons that have nothing to do with time travel and everything to do with how Git actually handles metadata.
Honestly, it’s kinda funny. You see a "10 years ago" tag on a PR merged yesterday and your brain immediately goes to: Did someone just wake up from a decade-long coma to fix this typo? Usually, the answer is way more boring, but the technical implications are actually pretty deep.
The ghost in the machine: How 10 year old commits happen
Git is a time machine, but it’s a time machine that trusts you way too much.
👉 See also: How to Not Get Ads on Spotify: What Actually Works Right Now
When you make a commit, Git stores two different dates: the Author Date and the Committer Date. Most of the time, they are the same. But they don't have to be. If you’re rebasing an ancient branch that’s been sitting in a dusty corner of a local drive, or if you’re manually setting the --date flag in your CLI, you can make a commit look like it happened during the Obama administration.
It’s usually a rebase gone wrong (or right)
Here is a common scenario. A developer starts a feature branch in 2015. They get busy. Life happens. The branch sits there, unmerged, gathering digital dust. Fast forward to 2025. They find the branch, run a git rebase main, and suddenly those original timestamps are preserved while the code is moved to the top of the history.
When that gets pushed to GitHub or GitLab, the UI sees that original author date. Boom. You've got 10 year old commits appearing at the top of your feed.
It also happens during repository migrations. When companies move from SVN to Git or from Bitbucket to GitHub, the migration tools try to preserve history. If the metadata mapping isn't perfect, or if it’s intentionally preserving the original "birth date" of the code, you end up with a repo that looks ancient but was "created" last week.
Why this actually matters for your security
You might think it’s just a visual glitch. It isn't.
Security researchers have been sounding the alarm on "timestomping" in Git repositories for a while now. Because Git allows you to forge the date of a commit easily, a malicious actor can hide a backdoor by backdating the commit to 2016.
💡 You might also like: Why the F/18 Super Hornet Still Matters in a Stealth World
Think about it. If you’re auditing a codebase and you see a commit from last Tuesday, you’re going to look at it closely. If you see a commit that says it was authored in 2014 by a developer who left the company years ago, you might skip right over it, assuming it’s "stable" legacy code.
Vulnerability scanning tools often prioritize newer changes. By leveraging 10 year old commits, an attacker can effectively bypass the "freshness" filters that many security teams rely on. It’s a clever, low-tech way to blend into the background.
The "Archaeology" of the Linux Kernel and Open Source
If you want to see real 10 year old commits that aren't glitches, go look at the Linux Kernel.
Working in those repos is basically digital archaeology. You’ll find code that hasn't been touched since 2005. It’s fascinating. You see names of legends like Linus Torvalds or Greg Kroah-Hartman attached to lines of code that are still running your phone and your smart fridge today.
The nuance of "stable" vs "stale"
There’s a massive difference between a commit that is 10 years old because it's perfect and one that's 10 years old because it's forgotten.
- Perfect code: Mathematical libraries or low-level drivers that do one thing and do it flawlessly. If the hardware hasn't changed, the code doesn't need to change.
- Stale code: A CSS file for a browser that doesn't exist anymore or a workaround for a bug in Python 2.4.
The problem is that GitHub’s UI doesn't always make it easy to tell which is which. You have to look at the context. You have to look at the blame.
Misconceptions about "Active" Repositories
We have this obsession with the "green square" contribution graph.
If a repo doesn't have a commit in the last six months, people think it's dead. That’s a mistake. Some of the most stable software in the world is full of 10 year old commits. It means the developers solved the problem so well a decade ago that nobody has needed to fix it since.
On the flip side, seeing a 10 year old commit in a fast-moving web framework is usually a red flag. It means there is a "dark corner" of the codebase that nobody understands well enough to refactor. It’s technical debt that has reached its tenth birthday.
How to fix (or embrace) the timeline warp
If you’ve accidentally pushed a bunch of ancient timestamps and your team is confused, you can fix it. But it’s a pain.
You’d have to use git filter-branch or the newer git filter-repo to rewrite the history and force the committer dates to match the current time. Warning: this changes commit hashes. If other people are working on the repo, you’re going to break their local copies.
Sometimes, it’s better to just leave it. It’s a conversation starter.
What to do when you encounter ancient commits
- Check the GPG signature. If the commit is 10 years old but signed with a key from 2024, something is up.
- Look at the committer date. Use
git log --format=fuller. This shows both the author date (when the code was written) and the committer date (when it was actually put into the current branch). - Don't panic. Most of the time, it’s just a dev who finally finished a very, very long-running task.
The Human Element
We forget that code is written by people.
A 10 year old commit is a snapshot of someone's brain from a decade ago. Maybe they were a junior dev then. Maybe they’re a CTO now. Seeing that old code can be embarrassing for the author, but for the rest of us, it’s a reminder of how far we’ve come.
It’s also a reminder that code lasts longer than we think. We write things today thinking they’ll be replaced in two years. History suggests that some of your work today will still be running in 2036. Write it like someone is going to be reading it ten years from now—because they probably will.
👉 See also: How to send timed messages on iPhone: Why Apple finally fixed its biggest annoyance
Actionable Steps for Managing Repository History
- Audit your migration tools: Before moving repos between platforms, test how they handle timestamps. Use flags that "reset" committer dates if you want a clean timeline.
- Use
git log --since: Don't let 10 year old commits clutter your view. Filter your logs to see what actually changed recently when doing code reviews. - Standardize rebase workflows: Teach your team to use
git rebase --committer-date-is-author-dateif they want to keep things looking "natural," or avoid it if they want the timeline to reflect when the work was actually integrated. - Verify signatures: Always require GPG or SSH signing for commits in sensitive environments. This ensures that even if a date is forged, the identity of the person pushing the code is verified.
- Check the "blame" carefully: When you see an old line of code, don't just assume it's "safe." Use
git blame -Cto see if that code was moved from another file, which can give you more context on its true age.
The presence of 10 year old commits is a quirk of the most powerful version control system ever built. It’s not a bug; it’s a feature of Git's flexibility. Understanding the difference between author dates and committer dates is the first step in mastering the "time travel" aspects of modern development. Keep your history clean, but don't be afraid of the ghosts in your codebase. They usually have a lot to teach you.