git-lfs

Git extension for versioning large files (by git-lfs)

Git-lfs Alternatives

Similar projects and alternatives to git-lfs

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better git-lfs alternative or higher similarity.

git-lfs reviews and mentions

Posts with mentions or reviews of git-lfs. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-12-29.
  • Golang is evil on shitty networks
    2 projects | reddit.com/r/programming | 29 Dec 2022
    git-lfs issue
    21 projects | news.ycombinator.com | 29 Dec 2022
    > And that pattern is the one that is used by GOs http libraries

    I don't think that is correct. In https://news.ycombinator.com/item?id=34213383, I notice that Go's HTTP/2 library would write the HEADERS frame, the DATA frame, and the terminal HEADERS frame in 3 different syscalls. In a sample application using the Go's HTTP/2 library, a gRPC response without Nagle's algorithm would transmit 497 bytes over 6 packets, while a gRPC response with Nagle's algorithm would transmit 275 bytes over 2 packets.

    With a starting point where both Nagle's algorithm and delayed ack are enabled, I guess this is the order of preference:

    1. delayed ack disabled, applications do the right thing by buffering accordingly - ideal performance, but it is difficult to disable delayed ack, and it may require a lot of works to fix the applications.

    2a. Nagle's algorithm disabled, applications do the right thing by buffering accordingly - almost ideal performance (may perform worse than #1 over bad connection), but it may require a lot of works to fix the applications.

    2b. delayed ack disabled, real world applications - almost ideal performance (may have higher syscall overhead than #1), but it is difficult to disable delayed ack.

    3. Nagle's algorithm disabled, real world application - not ideal as some applications can suffer from high packet overhead, e.g. git-lfs, and this is where we are at with Go.

    4. baseline - far from ideal as many applications can suffer from high latency due to bad interaction between Nagle's algorithm and delayed ack.

    I would say Go has made the right trade-off, albeit with a slight hint of "we know better than you". Going forward, it is probably cheaper for linux kernel to come up with a better API to disable delayed ack (i.e. to achieve #2b), than getting the affected applications to do the right thing by buffering accordingly (i.e. to achieve #1 or #2a). We will see how soon https://github.com/git-lfs/git-lfs/issues/5242 can be resolved.

    In the mean time, #2b can actually be achieved with a "SRE approach" by patching the kernel to remove delayed ack and patching the Go library to remove the `setNoDelay` call. Something for OP to try?

    21 projects | news.ycombinator.com | 29 Dec 2022
    git-lfs authors agree and point out regular git also disables Nagle.

    https://github.com/git-lfs/git-lfs/issues/5242

    21 projects | news.ycombinator.com | 29 Dec 2022
    > I will just add that it makes no sense at all that git-lfs (lf = large file!) should be sending large files 50 bytes at a time. That's a huge number of system calls that could be avoided by doing larger writes. And then the larger writes would work better for the TCP stack anyway.

    FWIW, at least one git-lfs contributor agrees with you: https://github.com/git-lfs/git-lfs/issues/5242#issuecomment-...

    > I think the first thing we should probably look at here is whether Git LFS (and the underlying Go libraries) are optimizing TCP socket writes or not. We should be avoiding making too many small writes where we can instead make a single larger one, and avoiding the "write-write-read" pattern if it appears anywhere in our code, so we don't have reads waiting on the final write in a sequence of writes. Regardless of the setting of TCP_NODELAY, any such changes should be a net benefit.

    21 projects | news.ycombinator.com | 29 Dec 2022
    }

    The write packet size seems to be determined by how much data the reader returns at a time. That could backfire if the reader were e.g. something like line at a time (no idea if something like that exists in Golang), but that does not seem to be the case here.

    [1] https://github.com/git-lfs/git-lfs/blob/d3716c9024083a45771c...

  • extreme super title
    11 projects | reddit.com/r/ProgrammerHumor | 16 Dec 2022
    Depending on the format an size of your map files, you might want to look into Git LFS
    11 projects | reddit.com/r/ProgrammerHumor | 16 Dec 2022
    May I introduce you to Git LFS?
  • How do you deal with large uncompressed WAV files in your game project?
    2 projects | reddit.com/r/gamedev | 1 Dec 2022
    If your final shipped solution only accepts WAV files then you must live with it. We use Github LFS for binaries. See https://git-lfs.github.com/
    2 projects | reddit.com/r/gamedev | 1 Dec 2022
  • Running Serverless ML on AWS Lambda
    3 projects | dev.to | 21 Nov 2022
    Because the pre-trained model is large, around 1 GB, we need a Git LFS extension installed to download it. Then we run:
  • A note from our sponsor - #<SponsorshipServiceOld:0x00007fea58edc138>
    www.saashub.com | 31 Jan 2023
    SaaSHub helps you find the best software and product alternatives Learn more →

Stats

Basic git-lfs repo stats
145
11,037
8.9
5 days ago
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com