There are two main fundamental things that cause problems with LFS:
LFS makes a 'centralised' assumption about Git usage. Git is designed to be decentralised, even if that's not how we use it, whereas LFS requires a single central object store. An example of where this is a problem: we do a lot of development for clients. It's very convenient to be able to mirror the git repo to their Gitlab and git usually makes it very easy. If you have LFS in your project then you have to jump through a lot of hoops.
The second problem is that LFS copies its data exclusively via https. This creates some security complexity if you normally authenticate via SSH.
Both of those could easily be solved if it were part of git proper, right? I don't see why not, or why they wouldn't be.
Regardless, I'm going to be sad if the UX we get to replace it is any of the newish/cutting-edge Git features, because they're damn ugly. In fact, despite how annoying LFS is for being a separate thing and requiring extra effort for server-side support if you're self-hosting, given Github and Gitlab (among others) support for LFS, I don't see things like sparse-checkout replacing it unless they get a lot nicer to use for that purpose specifically.
One thing that might help would be for Git to make distributing & sharing default repo config easy and built-in. Only thing that gets that treatment is the .gitignore. I feel like I need source control for my source control config, sometimes, and, indeed, some software's cropped up to do just that for e.g. hooks, but that ought to be built-in and cover more than that. One nice thing about LFS is that there's zero client-side config, aside from installing & enabling it (globally, if you like). You don't have to pass around lists of LFS-managed files or checkout-patterns or set-up scripts (hope you made them idempotent!) or anything out-of-band.
> Only thing that gets that treatment is the .gitignore [...] You don't have to pass around lists of LFS-managed files or checkout-patterns
I don't quite get this point. The .gitattributes file is key to the operation of LFS and is modified and passed around in exactly the same way as .gitignore.
Good point about .gitattributes files being another kind that gets passed around—but that doesn't help with things the .gitattributes file can't capture, which is most things and was part of my point about why making config natively-sharable would be generally nice and also would help to make things like sparse-checkout more useful; and, crucially, LFS Just Works™ without ever having to touch those files manually.
A good built-in implementation should do exactly what LFS does, yes. But they don't. LFS does, and that's part of why it's nicer to use for its specific purpose than doing something with shallow clones and sparse checkouts and all the rest. The best way to replace LFS in git itself would be to copy its UI as completely as possible, because it's pretty good.
Having to install & enable it is a pain, which making it part of git would fix. Having to maintain separate support for it server-side, and a separate transport mechanism, is a pain, which making it part of git at least could fix if the authors wanted to (in fact, I'd think it'd be more work not to solve that problem, in implementing it, though it'd leave vendors who want the two to be significantly separate to fend for themselves)
reply