The main argument here seems to be that we shouldn’t use LFS because Git will have large file support at some unspecified point in the future?
Similarly you could argue that we shouldn't use a Covid vaccine because we'll develop a cure in the future..why vaccinate billions of people when we can just treat the 1% of people who get ill?
Clearly that argument doesn't work. People need a solution now. Ironically we had to stop using mercurial because it didn't have an LFS alternative even though I prefer it. LFS is definitely not ideal but as a solution to a real world problem, it works. There may be issues around cloning repos and losing history in the future, but those are one off issues where you have to accept the pain, rather than living in pain every day.
Avoid Git LFS if possible
101–110 of 142 posts
Re: Avoid Git LFS if possible
#102Earlier quoted context omitted.
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.
Re: Avoid Git LFS if possible
#103git-annex is an interesting alternative the HTTP-first nature of Git LFS and the one-way door bother you. You can remove it after the fact if you don't like it, it supports a ton of protocols, and it's distributed just like git is (you can share the files managed by git-annex among different repos or even among different non-git backends such as S3). The main issue that git-annex does not solve is that, like Git LFS,…
dispite loving the idea of git annex and having tried it multiple time in my workflows, it was really to complex to wrap my head around for simple use cases. Also i never got it to run on cygwin which is essential to me because it heavily uses symlinks (havent checked if the Windows version finally supports native symlinks). The examples are all about nontech creative ppl but i never managed to explain it to anyone who wanted to check in just large amounts of graphics to a bit repo...
Re: Avoid Git LFS if possible
#104Earlier quoted context omitted.
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.
Re: Avoid Git LFS if possible
#105Earlier quoted context omitted.
It tracks the changes fine. It’s just that it doesn’t make sense to track changes in a binary.
It does make sense, and there are forms of delta compression particularly suited to various binary formats, which if combined with a unpacker for compressed files make great sense. However, git does not have an efficient binary diff implemented yet. LRzip happens to have such a format preprocessor that would make for exceedingly efficient binary history at cost of being more similar to git pack file than incremental…
In embedded almost everybody uses efficient binary delta diffs and patching for DFOTA (delta firmware over the air update). Jojodiff exists as GPL and MIT variants.
http://jojodiff.sourceforge.net/
https://github.com/janjongboom/janpatch
Rsync is also very popular, even if not that efficient. xdelta, bsdiff, BDelta, bdiff are all crap.
Re: Avoid Git LFS if possible
#106I keep hearing the mantra that "svn is better for large files than git" but never really understood why. To me a large file is a large file; if you make changes, worst case scenario you add the entire new file to the commit, best case you add some sort of binary diff. Does git do the former and svn the latter by any chance?
Re: Avoid Git LFS if possible
#107All three points are really just the same point repeated three times: That it isn't part of core/official GIT ("stop gap" until official, irreversible to later official solution, and adds complexity that an official version would lack due to extra/third party tooling). I'm frankly surprised GIT hasn't made LFS an official part by now. It fixes the problem, the problem is common and real, and GIT hasn't offered a bett…
LFS is definitely outside the scope of git.
It shouldn't be though.
Re: Avoid Git LFS if possible
#108I keep hearing the mantra that "svn is better for large files than git" but never really understood why. To me a large file is a large file; if you make changes, worst case scenario you add the entire new file to the commit, best case you add some sort of binary diff. Does git do the former and svn the latter by any chance?
An svn working copy has one version stored locally. A git clone has all versions stored locally. All versions of a large file takes up lots of space.
Re: Avoid Git LFS if possible
#109I 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 sy…
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.
Re: Avoid Git LFS if possible
#110As much as Git LFS is a bit of a pain, on recent projects I've resorted to committing my node_modules with Yarn 2 to Git using LFS and it works really well. Note that with Yarn 2 you're committing .tar.gz's of packages rather than the JS files themselves, so it lends itself quite well to LFS as there are a smaller number of large files. https://yarnpkg.com/features/zero-installs#how-do-you-reach-... https://yarnpkg.c…
why are you committing packages?
I would assume to prevent situations like the left-pad incident.