> Git’s content-addressed revision graph is excellent, but it treats binary files as second-class citizens—large files require bolted-on LFS rather than first-class chunked storage, sparse checkouts have sharp edges in offline use, and there is no native multi-tenant isolation.
I'm trying to figure out what Lore can accomplish that git+LFS can't. I've read about big binaries chunking, native interface and permission, is there anything else? Weren't those problems already solvable in the git+LFS ecosystem?
If you've used git+LFS for any extended period of times, you'd know how often it breaks, especially when used with forges like GitHub. Both GitHub and Git treat LFS as an after-thought and second class citizen.
Can you tell me where did it break? Or what feature you wished it had? I’m just curious, still trying to form an opinion on this.
I searched through my browser history to see what issues I googled the last time I used it, here is a non-exhaustive list:
- Auth errors with github because of different supports for various methods which results in the unhelpful "does not support the locking API error"
- Encountered files that should have been pointers but weren't errors
- Github handling the spec wrong such that file pointers that are invalid can make it through to Github such as multiple file pointers to the same file, but that have different line endings (issue 5410 on the git-lfs github if you want to see the details)
- Semi-frequent object does not exist on the server errors
- LFS support cannot be used on forks in github (you must instead manually clone the project and upload as un-related)
- Cloning with non-default ssh key is somewhat convoluted (issues 2842 2215 2727 4145 and 2433 on git-lfs)
Some of these are actual git-lfs issues which make using the usual git API break such as the auth/ssh-key stuff, whilst others are simply that it is much easier to get yourself into a bad state with git-lfs than vanilla git. Of course you can always get yourself out of a bad state by fresh-clone, or forcing etc.... but with large files this becomes a non-instant operation.
The fact that it's even referred to as git+LFS instead of just git... If I needed to work with large files frequently, I wouldn't want such a basic feature bolted on. Not a criticism of git, just can see why Epic doesn't use git.
I've used git+LFS for unity projects without much issue. If I was working with more than 2 people, I would definitely reach for something centralized.