Hacker News Reader

Comment by bentley | Hacker News Reader

Indeed. The proper thing (also read as: the friendliest way for distro packagers) is for software projects to generate and publish a tarball themselves as part of their tag+release process.

That provides multiple advantages. Unlike GitHub’s unreliable automatically generated files, a fixed file can be hashed or cryptographically signed by the project (with SSH signatures, Signify, PGP, etc.), and later verified without having to extract the files first or check out the underlying repo.

Another thing many projects aren’t aware of: if your project uses Git submodules, anyone using GitHub’s autogenerated tarballs will be unable to build your software, because those don’t contain submodules.

View on HN

> Unlike GitHub’s unreliable automatically generated files, a fixed file can be hashed or cryptographically signed by the project (with SSH signatures, Signify, PGP, etc.), and later verified without having to extract the files first

Or how about this: Microsoft could provide that as a feature in their "official release" page for projects, which is exactly what we all thought that page was for in the first place.

Seriously: if archive links are unreliable they're basically useless anyway. Who wants tarballs in the modern world except for package management or build automation?

People who want the source code but don't have `git`. It's also why downloading as a ZIP is also an option.

People who want the source code, don't have git, and won't get git in order to get the source code, sounds like the empty set. Though zip makes me think of windows, so maybe over there. The world of perforce.

Why?

I don't need git for my local personal use of the software, but I do need the source code if I need to modify the software.

Some people even downloaded source code even before git existed.

You need a compiler and a bunch of other build tools. Why not git?

What about people who don't have Git and want to build it from source?

> Indeed. The proper thing (also read as: the friendliest way for distro packagers) is for software projects to generate and publish a tarball themselves as part of their tag+release process.

And this is easy enough to do automatically with GitHub actions, I have a workflow [1] which runs on each release to create a stable archive of the source and attaches it to the release.

[1] https://github.com/elesiuta/picosnitch/blob/master/.github/w...

The proper thing is for the software build processes that rely on tarballs from GitHub to switch to using git directly; either by shallow clone or storing a full repo and checking out worktrees as appropriate. Tarballs at a tagged revision are fine as release artifacts if your upstream is publishing them as release artifacts, but the whole point of this is that they aren't.

Reply on news.ycombinator.com