[swiley]

LFS is definitely outside the scope of git.

[IshKebab]

It shouldn't be though.

[cerved]

Why do you think it should be within the scope of git?

[IshKebab]

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.

[cerved]

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

[IshKebab]

Ok but those are unreasonable things to do. Versioning large binary files is clearly not an unreasonable thing to want to do.

[cerved]

No but that doesn't mean a decentralized VCS is the best tool for the job. A file server may be sufficient and more efficient

[swiley]

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.

[IshKebab]

Version control of large files is clearly a reasonable thing for a version control system to do.

I think if you introspect you'll see you are defending a flaw in something you like with spurious technical objections because you don't want to admit it isn't perfect. That's understandable. Happens a lot.

[swiley]

I didn't say versioning large files isn't a reasonable thing to do, I said it doesn't make sense in git.

How is it supposed to work? The LFS way where you're storing a pointer to an external http resource? Just put a script in your repo to fetch that then.

Or maybe stick the data in git's merkle tree and have a really slow repo? Why bother with LFS then?