Hacker News Reader

Hacker News

Comment by wokwokwok | Hacker News Reader

Full thread

wokwokwok

I despise LFS.

I’m sure that if you know how to use it... maybe... you can figure it out.

That said; here’s my battle story:

Estimate the time it’ll take to move all our repositories from a to b they said.

Us: with all branches?

Them: just main and develop.

Us: you just clone and push to the new origin, it’s not zero but it’s trivial.

Weeks later...

Yeah. LFS is now banned.

LFS is not a distributed version control system; once you use it, a clone is no longer “as good” as the original, because it refers to a LFS server that is independent of your clone.

...also, actually cloning all the LFS content from git lab is both slow and occasionally broken in a way that requires you to restart the clone.

View on HN

I would rather maintain a handwritten journal of 1s and 0s than use git LFS again

honestly had no idea what git LFS was before seeing this, but okay then

You can easily mirror LFS objects by just using

git lfs fetch --all

every modern git hosting servers now have support for LFS directly inside the git server (gitlab, github, gerrit to my knowledge)

This solve the authentication issue nicely so make it easy for developers.

git lfs starts to be adopted by vendors and becomes usable. It solves real problem when you are tired of having to double your git server CPUs every 6 months as your git upload packs are taking huge time trying to recompress those big files over and over.

> It solves real problem when you are tired of having to double your git server CPUs every 6 months

Putting blobs into an SCM was always a bad idea, but in git it's particularly bad because the whole tree is always checked out at once. (I think last year a major change was added, that makes blob handling slightly more efficient though)

Still, I think there is still no independently developed git lfs server. I know, most people don't run git servers themselves but in the LFS use case it actually makes sense. There is also git annex which is completely open and free but adoption is very poor and the handling is even more obscure.

What is your alternative then? Version control binary files and have your repos grow gigabytes?

If you're rewriting files and need the version history, yes.

If you're not rewriting the files, also yes.

If you don't need the history, put them on a normal web server.

If you need history then still put them on a web server and increment the filenames. Storing large files in a git repo is a misappropriation of the tool. It wasn't designed for that use case.

I mean for me I'd like the convenience of having it all together. Oftentimes it would suffice if I could just store the current version of a binary efficiently in git. Marking it, so that git forgets the previous versions.

Currently I'm using an artifactory for this, but it would be much nicer if this could be integrated.

Reply on news.ycombinator.com