A signed commit and a blockchain-anchored timestamp answer different questions, and mixing them up costs you later. If you're trying to prove a release artifact, a document, or a piece of evidence existed at a specific point in time, and someone who doesn't trust you is going to check your work, the question isn't "which tool is better." It's which claim you actually need to defend: who touched this, or when it came into existence, independent of what anyone typed into a date field.

What signed git commits and tags is and how it works

Git has supported GPG commit and tag signing for years, and SSH-key signing since Git 2.34. Run git commit -S or git tag -s, and Git computes a cryptographic signature over the commit or tag object using your private key. git log --show-signature or git verify-commit checks that signature against a public key.

What the signature actually binds is the object's content: the tree hash, the parent hash, the author and committer fields, the message, and the committer date. Alter any of that after signing and the signature breaks. So a valid signature tells a verifier two things. First, whoever holds the private key produced this object. Second, nobody has changed the content since it was signed.

The committer date sits inside that signed content, which sounds like it should settle the timing question too. It doesn't. That date is a field the committer sets, not a value an outside system observes. It comes from your local clock by default, but git commit --date, the GIT_AUTHOR_DATE and GIT_COMMITTER_DATE environment variables, and history-rewriting tools like filter-branch or an interactive rebase with --committer-date-is-author-date can all put a different value there before the signature is applied. Sign a commit with a backdated timestamp and the signature verifies fine. It was never checking the date against anything outside the repository.

This isn't a flaw in commit signing. It's not what the feature is for. GPG and SSH signing exist to answer "did this key holder produce this exact content," and they answer it well. A verifier with your public key can confirm authorship and catch tampering. Neither of those is a claim about time.

The trust chain runs through key distribution: a keyserver, an SSH known_hosts entry, a web of trust, or a platform's own key registry (GitHub checks uploaded public keys to show its verified badge). None of that infrastructure has a role in the committer date. It was never asked to.

What ProofLedger does differently

ProofLedger anchors a SHA-256 hash of a file to Polygon and Bitcoin. It doesn't ask who you are and it doesn't parse the file for authorship. It anchors one hash and returns a proof tied to that anchoring event. The timestamp comes from block inclusion on two public chains, not from a field either party wrote by hand.

Only the hash leaves your machine. The file itself, the repository, the build artifact, the evidence document, stays where it is. Polygon confirms the anchor quickly; Bitcoin batches it in daily with a Merkle proof, giving you two independent chains a third party can check without asking ProofLedger to vouch for anything.

This is a narrower claim than commit signing makes, on purpose. It doesn't say who created the file. It says: this exact hash existed by this point, verifiable against two public ledgers neither you nor ProofLedger controls after the fact.

Verifying a proof yourself

Install the offline verification tool:

pip install verify-proof

Hash a file and check it against a stored proof, both entirely offline:

verify-proof hash myfile.pdf
verify-proof verify myfile.pdf --proof proof.json

Neither command touches the network. That's deliberate. Verification that depends on the issuing service isn't independent verification, so hash and verify recompute the digest locally and walk the Merkle path themselves.

Anyone, including opposing counsel or an auditor with no ProofLedger account, can also check a hash against the public record directly:

GET https://proofledger.io/api/v1/verify?hash=<sha256>

No authentication required. It returns whether the hash was found and, if so, the anchoring record and links to the underlying blockchain explorers, so the verification doesn't rest on trusting a party to the dispute.

Which fits your situation

If what you need to prove is that a specific person or key holder produced a commit, and that its content hasn't been altered since, commit signing does that job and nothing here replaces it. Keep signing your commits and tags. That's a real, solved problem in the identity and integrity domain.

If what you need to prove is that a file, a document, a release build, or a piece of evidence existed at a specific point in time, and you need that claim to hold up in front of someone who has every reason to doubt your say-so, a signed committer date doesn't get you there. It's a field you control, checked by a signature that only confirms you controlled it. In a dispute, the other side's first question is whether that date can be trusted, and the honest answer is: only as much as you trust the person who typed it.

That's the tradeoff under the signing-only model. The timing claim rests on self-reported metadata, cryptographically wrapped but still self-reported. Wrapping a number in a signature doesn't change who chose the number.

Anchor the hash separately when timing needs to survive that question. A dual-chain anchor gives you a timestamp neither party set, checkable against public ledgers by anyone, including whoever's disputing your version of events. Use both: sign your commits for authorship and integrity, and anchor the artifacts where the "when" is the fact someone will actually contest.