4 ms·
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
by wokwokwok 5y ago
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.
:(
- iab 5y agoI would rather maintain a handwritten journal of 1s and 0s than use git LFS again
- toomanyducks 5y agohonestly had no idea what git LFS was before seeing this, but okay then
- pooya13 5y agoWhat is your alternative then? Version control binary files and have your repos grow gigabytes?
- AstralStorm 5y agoIf 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.
- jmcnulty 5y agoIf 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.
- carlmr 5y agoI 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.
- tardyp 5y agoYou 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.
- blablabla123 5y ago> 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.