3 ms·

> 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

• handrous 5y ago
  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)