3 ms·

LFS is bad. The server implementations suck. It conflates object contents with the storage method. It's opt-in, in a terrible way - if you do the obvious thing

LFS is bad. The server implementations suck. It conflates object contents with the storage method. It's opt-in, in a terrible way - if you do the obvious thing you get tiny text files instead of the files you actually want. I dunno if their solution is any better but it's fairly unarguable that LFS is bad.

jayd16 1y ago
It does seem like this proposal has exactly the same issue. Unless this new method blocks cloning when unable to access the promisors, you'll end up with similar problems of broken large files.
- cowsandmilk 1y ago
  How so? This proposal doesn’t require you to run `git lfs install` to get the correct files…
  - jayd16 1y ago
    If the architecture is irrelevant and it's just a matter of turning it on by default they could have done that with LFS long ago.
    - thayne 1y ago
      Git lfs can't do it by default because: 1. It is a separate tool that has to be installed separately from git 2. It works by using git filters and git hooks, which need to be set up locally. Something built in to git doesn't have those problems.
      - xg15 1y ago
        But then they could have just taken the LFS plugin and made it a core part of git, if that were the only problems.
        thayne 1y ago
        If it didn't have those problems, it wouldn't really be git lfs, it would be something else.
  - vlovich123 1y ago
    And what happens when an object is missing from the cloud storage or that storage has been migrated multiple times and someone turns down the old storage that’s needed for archival versions?
    - atq2119 1y ago
      You obviously get errors in that case, which is not great. But GP's point was that there is an entire other category of errors with git-lfs that are eliminated with this more native approach. Git-lfs allows you to get into an inconsistent state e.g. when you interrupt a git action that just doesn't happen with native git.
      - jayd16 1y ago
        It's yet to be seen what it actually eliminates and what they're willing to actually enable by default. The architecture does seem to still be in the general framing of "treat large files as special and host them differently." That is the crux of the problem in the first place. I think it would shock no one to find that the official system also needs to be enabled and also falls back to a mode where it supports fetching and merging pointers without full file content. I do hope all the UX problems will be fixed. I just don't see them going away naturally and we have to put our trust in the hope that the git maintainers will make enjoyable, seamless and safe commands.
ozim 1y ago
I think maybe not storing large files in repo but managing those separately. Mostly I did not run into such use case but in general I don’t see any upsides trying to shove some big files together with code within repositories.
- tsimionescu 1y ago
  That is a complete no-go for many use cases. Large files can have exactly the same use cases as your code: you need to branch them, you need to know when and why they changed, you need to check how an old build with an old version of the large file worked, etc. Just because code tends to be small doesn't mean that all source files for a real program are going to be small too.
  - ozim 1y ago
    Yeah but GIT is not the tool for that. That is why I don’t understand why people „need to use GIT”. You still can make something else like keeping versions and keeping track of those versions in many different ways. You can store a reference in repo like a link or whatever.
    - mafuy 1y ago
      Git is the right tool. It's just bad at this job.
    - IshKebab 1y ago
      > Yeah but GIT is not the tool for that. Yes because Git currently is not good at tracking large file. That's not some fundamental property of Git; it can be improved. Btw it isn't GIT.
      - ozim 1y ago
        I care to disagree on it being an improvement or not being good at tracking large files being flaw of Git.

jayd16 1y ago

It does seem like this proposal has exactly the same issue. Unless this new method blocks cloning when unable to access the promisors, you'll end up with similar problems of broken large files.

cowsandmilk 1y ago
How so? This proposal doesn’t require you to run `git lfs install` to get the correct files…
- jayd16 1y ago
  If the architecture is irrelevant and it's just a matter of turning it on by default they could have done that with LFS long ago.
  - thayne 1y ago
    Git lfs can't do it by default because: 1. It is a separate tool that has to be installed separately from git 2. It works by using git filters and git hooks, which need to be set up locally. Something built in to git doesn't have those problems.
    - xg15 1y ago
      But then they could have just taken the LFS plugin and made it a core part of git, if that were the only problems.
      - thayne 1y ago
        If it didn't have those problems, it wouldn't really be git lfs, it would be something else.
- vlovich123 1y ago
  And what happens when an object is missing from the cloud storage or that storage has been migrated multiple times and someone turns down the old storage that’s needed for archival versions?
  - atq2119 1y ago
    You obviously get errors in that case, which is not great. But GP's point was that there is an entire other category of errors with git-lfs that are eliminated with this more native approach. Git-lfs allows you to get into an inconsistent state e.g. when you interrupt a git action that just doesn't happen with native git.
    - jayd16 1y ago
      It's yet to be seen what it actually eliminates and what they're willing to actually enable by default. The architecture does seem to still be in the general framing of "treat large files as special and host them differently." That is the crux of the problem in the first place. I think it would shock no one to find that the official system also needs to be enabled and also falls back to a mode where it supports fetching and merging pointers without full file content. I do hope all the UX problems will be fixed. I just don't see them going away naturally and we have to put our trust in the hope that the git maintainers will make enjoyable, seamless and safe commands.

ozim 1y ago

I think maybe not storing large files in repo but managing those separately. Mostly I did not run into such use case but in general I don’t see any upsides trying to shove some big files together with code within repositories.

tsimionescu 1y ago
That is a complete no-go for many use cases. Large files can have exactly the same use cases as your code: you need to branch them, you need to know when and why they changed, you need to check how an old build with an old version of the large file worked, etc. Just because code tends to be small doesn't mean that all source files for a real program are going to be small too.
- ozim 1y ago
  Yeah but GIT is not the tool for that. That is why I don’t understand why people „need to use GIT”. You still can make something else like keeping versions and keeping track of those versions in many different ways. You can store a reference in repo like a link or whatever.
  - mafuy 1y ago
    Git is the right tool. It's just bad at this job.
  - IshKebab 1y ago
    > Yeah but GIT is not the tool for that. Yes because Git currently is not good at tracking large file. That's not some fundamental property of Git; it can be improved. Btw it isn't GIT.
    - ozim 1y ago
      I care to disagree on it being an improvement or not being good at tracking large files being flaw of Git.