Planning on some monorepo features soon that should solve some submodule problems but haven't approached yet. I have some new ideas here. And yes, no separate LFS system!
I'm a little confused by this but I assume you're talking about marking files for LFS (.gitattributes)? For us, we chunk every file (even if it's a single chunk) so every file is stored in the same way -- it's just data to us. But let me know if I got your question wrong.
So the problem that LFS solves is that sometimes you have large files that you a) don't want to download by default, e.g. old binary executables, b) are big enough that you want to serve them from a more efficient source e.g. S3, or c) are large and not needed forever, so you want to be able to delete them one day.
LFS "solves" those but it does it really badly. Really really badly. I've probably forgotten all the ways, but at least:
1. It conflates the content with the storage mechanism. You can't change retrospectively how the files are stored, even though the only thing you really need to be immutable is their content.
2. It requires you to actively set up git-lfs, otherwise it silently does the wrong thing.
3. Not exactly LFS's fault but I have yet to find a forge (GitHub, Gitlab etc.) which exposes the LFS stored files in a sane way. Last time I tried it was basically impossible to delete old files, and you needed a lot of extra work to even enable LFS in the place.
Yes Lore looks awesome! I was previously working on a VCS for gamedevs -- that space definitely needs something better than Perforce haha. My comment would be that I think you need to nail a new GitHub + Git to really be successful in the space and I'm not sure Epic is focused on this. I wonder if Lore will turn out similar to Unity Version Control which is very specialized to Unity workflows or something more general. Definitely love what they're doing though.
Awesome. How does one decide which files should be stored externally, and manage that? And where is that decision stored?