Earlier quoted context omitted.
It shouldn't be though.
Why do you think it should be within the scope of git?
Because it's something that lots of people want to use Git for, and because it would work better if it were a core part of Git.
Avoid Git LFS if possible
121–130 of 142 posts
Re: Avoid Git LFS if possible
#122I've been using Git LFS with several large Unity projects in the past several years. Never really had any problems. It was always just "enable and forget" kind of thing.
Yeah, unless you can avoid large files entirely, or are okay with a separate tool (this pisses of a lot of devs IME), then just don't use git? I don't like that option. I think this is sensational. At this point LFS is a really big deal. I don't think it's going anywhere or that LFS users will be shafted.
Re: Avoid Git LFS if possible
#123I 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?
For a sizeable project, or one with lots of binary commits, eg. 1-10 GB sized items per day... that type of thing, you have to use LFS or SVN.
Your repo size could easily balloon to terabytes, for every clone. Additionally, I think there's other performance issues, but I don't allow this to happen, so I'm not sure.
SVN happily handles terabytes, due to the client server interface. As does LFS. My biggest gripe with LFS is that it turns your distributed tool into a client server one. I kinda wish they had and easy "skip lfs" type option.
Re: Avoid Git LFS if possible
#124Pushing Github past the 100mb limit has to be the most requested feature. Ridiculous that we have to use the fudge that is GitLFS. It just adds complication for a limit that shouldn't be there anyway.
You can use gitlab instead with a few GB limit instead.
You can also self host with GOGS / Gitea and no limit but getting my company to move from Github will be a large undertaking. It's not worth it for GitLFS on it's own.
Re: Avoid Git LFS if possible
#125Earlier quoted context omitted.
Yea i actually wrote my own file chunking and general git-lfs-like backend for this exact reason. I liked Git LFS, but Github's pricing felt insane for my indie dev. For my needs i could backup onto a local server, network drive, or w/e at an insanely cheaper price. Hell even uploading to an S3 compatible API was insanely cheaper than Github. That and i really hated the feeling that Git LFS was being designed for a s…
Do you have a repo for it?
I do, but i'm not comfortable sharing it. It's an experimental project, very new, and not polished enough for general use. A POC if you will. Plus this is an anonymous account :P
While i was writing it i found the basic process of basic large file storage to be insanely simple with Git. I debated doing the same thing but backed by a seasoned backup solution, like Borg/Bup/etc.
Re: Avoid Git LFS if possible
#126Earlier quoted context omitted.
Why do you think it should be within the scope of git?
Because it's something that lots of people want to use Git for, and because it would work better if it were a core part of Git.
Maybe I want to use vim as an interactive WYSIWYG modeling program but that doesn't mean it's in the scope of the project.
LFS belongs in your build scripts, the model the git extension use doesn't even match the git VCS model.
Re: Avoid Git LFS if possible
#127git-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 w…
I don't know about the windows problem, but git annex can be configured to be pretty simple to use. See:
https://bryan-murdock.blogspot.com/2020/03/git-annex-is-grea...
Re: Avoid Git LFS if possible
#128Earlier quoted context omitted.
So I decided to check this out. Used dd if=/dev/random to create a 100mb file, checked that in, used dd again to modify 10mb of that file, checked that in and the result were two 98mb objects. Tracking changes of binaries makes a lot of sense if you use that to only store incremental changes to the file. Git stores each modification of a binary file as a separate blob since it doesn't know how to track its changes. T…
Git LFS has the advantage of not pulling all versions of a large file, too. Instead, it only pulls the version it's checking out. In our project it helped dramatically as you only pull X MB instead of X * Y MB when a CI or developer clone the (already big) repo.
This is true. Git-LFS can dramatically increase the size of the repository on-disk (e.g. in our GitLab cluster), but dramatically decrease the size of the clone a user must perform to get to work.
Note that this can now be accomplished with Git directly, by using --filter=blob:none when you clone; this will cause Git to basically lazy-load blobs (i.e. file contents) by only downloading blobs from the server when necessary (i.e. when checkout out, when doing a diff, etc).
Re: Avoid Git LFS if possible
#129Earlier quoted context omitted.
Why do you think it should be within the scope of git?
Because it's something that lots of people want to use Git for, and because it would work better if it were a core part of Git.
okay, but why?
Lots of people want to use document databases as if they were relational, lots of people want to use their RDBMS as a file server and lots of people use spreadsheets for just about everything.
Lots of people wanting to use a product in certain way doesn't mean it's a good idea, nor that someone else should make that work for them that way
Re: Avoid Git LFS if possible
#130Earlier quoted context omitted.
I prefer keeping large files out of source control and thus far I've not encountered a problem where their introduction has been required.
While I share the sentiment of keeping large files out of source control, one use-case I believe warrants having large files in source control is game development.
that's about the only conceivable niche I can think of, even then I'm skeptical about turning the VCS into an asset manager
You can't diff and I'm not not convinced the VCS should carry the burden of version controlling assets. Seems better to have a separate dedicated system for such purposes
Then again I don't do game development so I'm not familiar with the requirements of such projects