Every developer has said it at least once: "check the git log — it's all there." Commit date, author, diff — it looks like an irrefutable timeline of who wrote what and when. It isn't. And if you ever need to prove authorship or priority of code — in a dispute with a former co-founder, a contested termination involving IP, a licensing or patent dispute — you'll find that git log means far less than it appears to. Commit dates are just a field you can rewrite git commit --date lets you set any date when creating a commit. git rebase -i, combined with manual editing or --committer-date-is-author-date, rewrites history entirely. git filter-branch and its modern replacement git filter-repo change dates and authorship across batches of commits in seconds. Nothing in git itself prevents you from creating a commit today with a date stamped "three months ago." Git is a version control system, not a proof-of-time system. It was never designed for this — and that's fine, as long as you understand what it actually guarantees. Force-push erases history without a trace If a repository isn't protected by explicit branch protection rules, git push --force overwrites the remote history completely. What was in main yesterday may simply not exist today — no warning, no record of the fact anywhere else. GitHub keeps a reflog for a while, but that's not a guarantee — reflogs get cleaned up, forks may be out of sync, and if a dispute ends up in court, "it might still be somewhere in GitHub's logs" isn't something you want to rely on. Anyone with write access can rewrite history after the fact This is the key issue in priority disputes: if two people have access to the same repository — co-founders, a team — both of them physically have the ability to rewrite the shared history. Git doesn't verify "who came up with this first"; it only verifies "what's currently in the database," and that database is mutable by anyone with push access. When the dispute is real — not hypothetical — the question "whose git log is more trustworthy" becomes part of the dispute itself, not a way to resolve it. GPG-signed commits solve only part of the problem Signed commits (git commit -S) genuinely prove that a specific person with a specific key confirmed specific content. That's valuable — but it doesn't solve the time question. A signature doesn't carry an independently verified timestamp; it confirms what, not when it was actually created, if the commit date itself — the very field you can rewrite — was set before signing. What you actually need to prove priority To make date and content genuinely unfalsifiable, you need a timestamp that neither party to the dispute controls — an independent third party that recorded a hash of the content at a specific moment, before there was any reason to falsify it. This is exactly what notaries used to do with paper documents, and what an RFC 3161 Time-Stamping Authority (TSA) does for digital data — an independent, cryptographically verified timestamp over a content hash, issued by a party with no stake in the outcome of your dispute. In practice, this means keeping an independent record — alongside your git repository, not instead of it — of key milestones: releases, critical commits, the state of your codebase on dates that matter, anchored to an external, immutable source of truth. Not paranoia, just basic hygiene Most repositories will never need this — if a dispute never arises, git log does its normal job perfectly well. But for developers working in startups with multiple co-founders, freelancers handing off code to clients, teams protecting their own algorithms as trade secrets — the cost of one unresolvable authorship dispute is usually far higher than the few minutes it takes to independently anchor an important commit ahead of time. It's cheaper to record it once, before you need it, than to try to prove anything after the fact with tools that were never built for that purpose. Evident Ledger — independent cryptographic file anchoring with an external RFC 3161 timestamp. Local utility, open verification model, free base tier.
Why Your Git History Isn't Enough as Proof
Full Article
📰 Original Source
Read full article at Dev →KhanList aggregates and links to publicly available news content. We do not host full articles from third-party sources. Always verify important information with original sources.