SaaSHub helps you find the best software and product alternatives Learn more →
Git-lfs Alternatives
Similar projects and alternatives to git-lfs
-
-
-
SonarQube
Static code analysis for 29 languages.. Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.
-
-
-
-
git-fat
Simple way to handle fat files without committing them to git, supports synchronization using rsync (by jedbrown)
-
-
InfluxDB
Build time-series-based applications quickly and at scale.. InfluxDB is the Time Series Platform where developers build real-time applications for analytics, IoT and cloud-native services. Easy to start, it is available in the cloud or on-premises.
-
-
-
Caddy
Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS
-
bfg-repo-cleaner
Removes large or troublesome blobs like git-filter-branch does, but faster. And written in Scala
-
-
scalar
Scalar: A set of tools and extensions for Git to allow very large monorepos to run on Git without a virtualization layer
-
logseq
A local-first, non-linear, outliner notebook for organizing and sharing your personal knowledge base. Use it to organize your todo list, to write your journals, or to record your unique life.
-
-
simple-ps5-ui
A next.js application, made to be a simple replication of the PS5 User interface.
-
cloudwithchris.com
Cloud With Chris is my personal blogging, podcasting and vlogging platform where I talk about all things cloud. I also invite guests to talk about their experiences with the cloud and hear about lessons learned along their journey.
-
home-repo
Home Repo 🚢 - Raspberry Pi based home development system including: git repo, CI/CD pipelines, docker registry, and monitoring.
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
git-lfs reviews and mentions
-
Golang is evil on shitty networks
git-lfs issue
> 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?
git-lfs authors agree and point out regular git also disables Nagle.
> 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.
}
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
Depending on the format an size of your map files, you might want to look into Git LFS
May I introduce you to Git LFS?
-
How do you deal with large uncompressed WAV files in your game project?
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/
-
Running Serverless ML on AWS Lambda
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
Stats
git-lfs/git-lfs is an open source project licensed under GNU General Public License v3.0 or later which is an OSI approved license.