6 ms·

I can’t tell what the use case is, or how it varies from git/git push.

ChrisMarshallNY 3y ago
> Regardless whether you're using small text files or huge binary files, Darke Files handles them all. That is interesting to game developers and creatives (like movie EFX folks). They can have huge assets, and Git is pretty terrible at large binaries. That's why Perforce is still popular in the gaming industry. It handles big files, very well.
- throwaway290 3y ago
  Does Git LFS have issues?
  - hammyhavoc 3y ago
    LFS can have issues, e.g., if using HTTPS alongside SSH is going to be a problem. It's also not a part of the core git project, but neither of these things may matter to you. There's other caveats, but they go with the territory of the benefits gained from LFS. For me, it works fine in Gitea, and I do audio and music for games. Are there more appropriate solutions like Perforce? Probably, but the current pipeline is git-based.
    - throwaway290 3y ago
      Thanks, interesting to hear a perspective of someone who versions media in Git. Also going to check out your music!
  - remram 3y ago
    Git LFS is very slow for lots of files. It is also inefficient space-wise and bandwidth-wise if you update big files. The integration with Git is also very clunky since it's based on smudge/clean filters (that were really meant to update templates in your text files or change line endings, not download big files). The server options are also limited and not easy to deploy. Not a problem if you use a central repository on the cloud, but a non-starter if you want direct sync between devices.
    - throwaway290 3y ago
      Where is the inefficiency, Git LFS spec or some particular server? I think space is not a spec issue at all, an LFS server can use any deduplicating storage under the hood The part where filters are used is not elegant, porcelain for LFS could be better.
      - unshavedyak 3y ago
        For me it's just that Git LFS defaults to a server. I'm rewriting it largely because i loathe Git-LFS needing to hit some HTTP server. Running one locally because they defaulted to a Github Webserver mindset frustrates me.
        throwaway290 3y ago
        Personally if files are large I prefer to store all of them and the entire history of their changes somewhere else, so a server makes sense to me...
        unshavedyak 3y ago
        Yea, i just don't want to be forced to. Ie to me storing them in another folder, a network filesystem, some SSH filesystem, a dumb KV store like S3, etc are all viable storage locations to it. So that's what i'm writing because i'm just picky, i guess heh.
        throwaway290 3y ago
        The spec says pointer is just an URL so it could probably be a file:... or s3:... URL if you have the right resolver logic
      - remram 3y ago
        > I think space is not a spec issue at all, an LFS server can use any deduplicating storage under the hood The client doesn't deduplicate, so you have to download whole objects and store them. Of course you can clean up the older version of objects, but that will force you to re-download if you change branch or go back in the history.
Fnoord 3y ago
Either way, its not ready for production. FTA: > Can I start using this right now? > Darke Files is still alpha software so please don't use it in production. Additionally Darke Files is missing many missing many features one might expect from a version control system (or a software forge, or a devops platform). Keep good backups of your data if you decide to try it out.

> Regardless whether you're using small text files or huge binary files, Darke Files handles them all. That is interesting to game developers and creatives (like movie EFX folks). They can have huge assets, and Git is pretty terrible at large binaries. That's why Perforce is still popular in the gaming industry. It handles big files, very well.

throwaway290 3y ago
Does Git LFS have issues?
- hammyhavoc 3y ago
  LFS can have issues, e.g., if using HTTPS alongside SSH is going to be a problem. It's also not a part of the core git project, but neither of these things may matter to you. There's other caveats, but they go with the territory of the benefits gained from LFS. For me, it works fine in Gitea, and I do audio and music for games. Are there more appropriate solutions like Perforce? Probably, but the current pipeline is git-based.
  - throwaway290 3y ago
    Thanks, interesting to hear a perspective of someone who versions media in Git. Also going to check out your music!
- remram 3y ago
  Git LFS is very slow for lots of files. It is also inefficient space-wise and bandwidth-wise if you update big files. The integration with Git is also very clunky since it's based on smudge/clean filters (that were really meant to update templates in your text files or change line endings, not download big files). The server options are also limited and not easy to deploy. Not a problem if you use a central repository on the cloud, but a non-starter if you want direct sync between devices.
  - throwaway290 3y ago
    Where is the inefficiency, Git LFS spec or some particular server? I think space is not a spec issue at all, an LFS server can use any deduplicating storage under the hood The part where filters are used is not elegant, porcelain for LFS could be better.
    - unshavedyak 3y ago
      For me it's just that Git LFS defaults to a server. I'm rewriting it largely because i loathe Git-LFS needing to hit some HTTP server. Running one locally because they defaulted to a Github Webserver mindset frustrates me.
      - throwaway290 3y ago
        Personally if files are large I prefer to store all of them and the entire history of their changes somewhere else, so a server makes sense to me...
        unshavedyak 3y ago
        Yea, i just don't want to be forced to. Ie to me storing them in another folder, a network filesystem, some SSH filesystem, a dumb KV store like S3, etc are all viable storage locations to it. So that's what i'm writing because i'm just picky, i guess heh.
        throwaway290 3y ago
        The spec says pointer is just an URL so it could probably be a file:... or s3:... URL if you have the right resolver logic
    - remram 3y ago
      > I think space is not a spec issue at all, an LFS server can use any deduplicating storage under the hood The client doesn't deduplicate, so you have to download whole objects and store them. Of course you can clean up the older version of objects, but that will force you to re-download if you change branch or go back in the history.

Fnoord 3y ago

Either way, its not ready for production. FTA: > Can I start using this right now? > Darke Files is still alpha software so please don't use it in production. Additionally Darke Files is missing many missing many features one might expect from a version control system (or a software forge, or a devops platform). Keep good backups of your data if you decide to try it out.