> Why do we distribute tarballs at all? A git hash should be all thats needed...

A git hash means nothing without the repository it came from, so you'd need to distribute both. A tarball is a self-contained artifact. If I store a tarball in a CD-ROM, and look at it twenty years later, it will still have the same complete code; if I store a git hash in a CD-ROM, without storing a copy of the repository together with it, twenty years later there's a good chance that the repository is no longer available.

We could distribute the git hash together with a shallow copy of the repository (we don't actually need the history as long as the commit with its trees and blobs is there), but that's just reinventing a tarball with more steps.

(Setting aside that currently git hashes use SHA-1, which is not considered strong enough.)

except it isn't reinventing the tarball, because the git hash forces verification that every single file in the repo matches that in the release.

And git even has support for "compressed git repo in a file" or "shallow git repo in a file" or even "diffs from the last release, compressed in a file". They're called "git bundle"'s.

They're literally perfect for software distribution and archiving.

People don't know how to use git hashes, and it's not been "done". Whereas downloading tarballs and verifying hashes of the tarball has been "good enough" because the real thing it's been detecting is communication faults, not supply chain attacks.

People also like version numbers like 2.5.1 but that's not a hash, and you can only indirectly make it a hash.