4 ms·

> Nowadays, the repo-tarball split is largely unnecessary I think locking the source distribution mechanism to only git would be detrimental in the grand schem

> Nowadays, the repo-tarball split is largely unnecessary I think locking the source distribution mechanism to only git would be detrimental in the grand scheme. A source tarball is universal, independent of preferred tooling, easy to hash, sign and verify, and archive. Even git has loopholes in that a tag does not necessarily have to be a part of the master branch, and not everyone uses (or wants to use) github, or a similar online interface for git... It's also worth considering that source generation tools are often keen to changing their API frequently, while their output is more weaponized against the passage of time. Autotools is significantly better about that these days, but many other tools aren't...

kevincox 3y ago
I think most packagers that can pull from Git can also pull from Mercurial, SVN or whatever else. Pulling from Git doesn't really require using GitHub other than connecting to their IP. You don't need an account or any tool other than Git to clone a public repo. It seems to me that pulling directly from the primary source of truth is a good idea these days where possible.
kruador 3y ago
The Git protocol is also substantially more heavyweight than just downloading a tarball. 'Dumb' HTTP involves requesting `info/refs` which lists all the references (branches and tags) available. The client has to find the tag you want, then request the corresponding commit object. That lists the hash of the tree object, which has to be requested, and recursively the tree object references other trees and finally the file blobs. Any object request could fail because the object isn't stored 'loose' on disk, but is instead in a pack. So the client first downloads `objects/info/http-alternates` to see if it's in a different location, then if that doesn't list anything, it asks for the list of packs `objects/info/packs`. Then it asks for the index of each pack to determine which pack contains the object, then finally downloads that pack. Because that's very slow, Git also supports 'Smart' HTTP. That moves all the lookups server-side, with a back-and-forth between client and server about what the client has and what it wants, ultimately building a custom pack containing what you asked for. This obviously can't be cached. In contrast a tarball is one request for one file on disk which is fully cacheable, both by the server hosting the file and any proxies on the path. This is why things like `bower` and `DefinitelyTyped` got deprecated. Some of them were even hosting the registry itself as a Git repository on GitHub.
- Kwpolska 3y ago
  GitHub/GitLab can generate tarballs from specific git commits, and those are cacheable and don’t change (when GitHub deployed some changes to the format, many places noticed and GitHub had to undo the changes).
  - mid-kid 3y ago
    That's just a shortcut to the conventional tarball distribution method.

kevincox 3y ago

I think most packagers that can pull from Git can also pull from Mercurial, SVN or whatever else. Pulling from Git doesn't really require using GitHub other than connecting to their IP. You don't need an account or any tool other than Git to clone a public repo. It seems to me that pulling directly from the primary source of truth is a good idea these days where possible.

kruador 3y ago

The Git protocol is also substantially more heavyweight than just downloading a tarball. 'Dumb' HTTP involves requesting `info/refs` which lists all the references (branches and tags) available. The client has to find the tag you want, then request the corresponding commit object. That lists the hash of the tree object, which has to be requested, and recursively the tree object references other trees and finally the file blobs. Any object request could fail because the object isn't stored 'loose' on disk, but is instead in a pack. So the client first downloads `objects/info/http-alternates` to see if it's in a different location, then if that doesn't list anything, it asks for the list of packs `objects/info/packs`. Then it asks for the index of each pack to determine which pack contains the object, then finally downloads that pack. Because that's very slow, Git also supports 'Smart' HTTP. That moves all the lookups server-side, with a back-and-forth between client and server about what the client has and what it wants, ultimately building a custom pack containing what you asked for. This obviously can't be cached. In contrast a tarball is one request for one file on disk which is fully cacheable, both by the server hosting the file and any proxies on the path. This is why things like `bower` and `DefinitelyTyped` got deprecated. Some of them were even hosting the registry itself as a Git repository on GitHub.

Kwpolska 3y ago
GitHub/GitLab can generate tarballs from specific git commits, and those are cacheable and don’t change (when GitHub deployed some changes to the format, many places noticed and GitHub had to undo the changes).
- mid-kid 3y ago
  That's just a shortcut to the conventional tarball distribution method.