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.
Top comments (2)
Wouldn't git-tuf also solve this issue (with its append-only log; though I am not sure if it cannot be truncated)? There is also signed pushes and ref transparency log (but the second is service external to Git).
Great points, and you're right that these are real architectural improvements — worth being precise about what each one actually solves.
gittuf's append-only log is a genuine step forward for tamper-evidence within the repository's own infrastructure — but the neutrality question stays open: who hosts that log, and is it beyond the control of both parties to a potential dispute? If it's self-hosted or GitHub-hosted, it's still, in principle, within the trust boundary of at least one interested party. The truncation question you raised is exactly the crux of it.
Signed pushes are great for proving who pushed what — but the timestamp inside a push certificate still typically comes from the pusher's own clock, not an independently verified source. That's the same gap GPG-signed commits have: strong on authorship, silent on independently-verifiable time.
The reference transparency log is actually the closest analog to what the article is arguing for — and you already flagged the key point yourself: it's external to git. That's not a bug in your argument, that's the argument. Once you need a neutral, publicly-auditable source of truth for when, you've stepped outside git's trust model by design — which is exactly the RFC 3161 TSA angle from the post, just via a different mechanism (Merkle-log transparency vs. RFC 3161 timestamping authority).
So I'd put it this way: gittuf + signed pushes meaningfully raise the bar for tamper-evidence inside your git workflow, but none of them (by your own framing of the transparency log) eliminate the need for an external, independent point of reference once a dispute is real and both parties' git infra is itself in question.