Skip to content

Comment on GitHub’s Large File Storage is no panacea for Open Source

Comments

I'm not sure I understand why artifacts can't be stored in a different service - even an S3 bucket, if not a real repository service - and fetched dynamically via a build process.

Is there a reason why binary blobs need to be stored directly next to code in order to be versioned?

The way I understand it, it should be possible, though it's more complicated since they seem to infer the LFS URL from the repo URL by default. So if you wanted to say keep your repo on Github, and store your LFS files on S3, you'd need to explicitly tell git where to write the files. There are configuration values for that.

Also you'd need the necessary LFS server piece on Amazon's side.

I'm thinking that rather than using git for versioning the binary artifacts as well, you tag and version your git repo, then tag and name/label your artifacts in another storage service. You then allow a build tool to assemble from both locations.

Aside from a second point of failure, how does this integrate with anything? When you push, what piece of software pushes what where? And who pays?

You can put this sort of build framework together with whatever tool you're using (gradle, maven, rake, grunt etc).

The idea isn't to shove everything into a storage bucket, but to assemble a toolchain using components that are fit for purpose. Git is fundamentally not fit for purpose as an artifact repository. There are tools that are.

-Eric

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.