{"slug": "git-lfs", "name": "Git LFS", "category": "git", "category_name": "Git and code hosting", "description": "", "recommenders": 2, "commenters": 8, "warners": 5, "score": -2.469, "rising": 2.0, "first": "2026-06-17", "latest": "2026-09-11", "why": "I use git+lfs for unity projects and it works out great.", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 2, "neutral": 1, "compare": 0, "warn": 5}, "spark": [0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0], "listed": false, "loved": [], "caveat": "", "short_quote": "I use git+lfs for unity projects and it works out great.", "icon": false, "domain": null, "github_repo": null, "official_url": "", "pricing": "", "aliases": ["Git LFS", "git-lfs"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 794232608, "item_id": 49639538, "url": "https://news.ycombinator.com/item?id=49639538", "by": "bob1029", "date": "2026-09-10", "stance": "recommend", "quote": "I use git+lfs for unity projects and it works out great.", "excerpt": "It sounds like the author went through a lot of pain to avoid using git+lfs or perforce. I use git+lfs for unity projects and it works out great. If I had a real studio I'd buy some perforce seats. Reinventing the wheel like this is quite exhausting. There are options that are proven to work. AI authorship does not fundamentally violate the idea of some thing owning a specific commit. We don't need new schemas in our", "context": "", "use_case": "Unity project version control", "switched_from": "", "story": "Version control second coming"}, {"id": 790896065, "item_id": 49431004, "url": "https://news.ycombinator.com/item?id=49431004", "by": "lionkor", "date": "2026-08-25", "stance": "recommend", "quote": "There's Git LFS, that hooks up an object store (like S3) to git for large files.", "excerpt": "I struggle very much to understand the \"why\". There's a git server, it's installed when you install git, and it really does work very well. > every instance is a disposable cache that revalidates with one conditional GET. No database, no Redis, no gossip, no leader, no node identity. Git famously doesn't use that either...? What is the point? > \"just put the repositories on NFS\" failed at every large host that tried ", "context": "", "use_case": "large files in git", "switched_from": "", "story": "Walgit \u2013 a Git server that is one binary in front of an object store"}]}], "caveats": [{"label": "", "summary": "", "quotes": [{"id": 794438752, "item_id": 49652422, "url": "https://news.ycombinator.com/item?id=49652422", "by": "MindSpunk", "date": "2026-09-11", "stance": "warn", "quote": "I've found LFS very brittle when bouncing between branches and moving around in history.", "excerpt": "> Git and P4 are not meant to be directly competitive here. True, but for the problems that Git LFS solves P4 is usually the other option. P4 handles large binaries very well, caveat being the rest of P4. In some projects the caveats are worth it. I work in video games and our in house engine has an unfiltered checkout size over a 1TB. I've found LFS very brittle when bouncing between branches and moving around in hi", "context": "works in video games with a 1TB repo", "use_case": "large binaries in game dev", "switched_from": "", "story": "Version control second coming"}, {"id": 794244112, "item_id": 49640257, "url": "https://news.ycombinator.com/item?id=49640257", "by": "MindSpunk", "date": "2026-09-10", "stance": "warn", "quote": "Git LFS is extremely brittle and will break your local check out if you so much as breath on it wrong", "excerpt": "From my experience Git LFS is extremely brittle and will break your local check out if you so much as breath on it wrong. Perforce is an expensive solution to the problems of LFS, and I've yet to find a workflow as powerful as my git workflows for managing code. I don't really see what the article is talking about as the future, but if P4 or Git LFS is the best we can do as a species then we're doomed. All VCS option", "context": "", "use_case": "versioning large files", "switched_from": "", "story": "Version control second coming"}, {"id": 790155936, "item_id": 49384746, "url": "https://news.ycombinator.com/item?id=49384746", "by": "cfjgvjh", "date": "2026-08-21", "stance": "warn", "quote": "I tried using LFS as well but it didn't work for my specific workflow.", "excerpt": "I really really want to do version control for everything, but most of my data is binary so it really doesn't agree with git; I tried using LFS as well but it didn't work for my specific workflow. Hopefully something less text oriented comes along in the future. Lore looked interesting for this purpose. https://github.com/EpicGames/lore", "context": "", "use_case": "versioning binary data", "switched_from": "", "story": "Version Control for Everything"}, {"id": 777337200, "item_id": 48583575, "url": "https://news.ycombinator.com/item?id=48583575", "by": "zipy124", "date": "2026-06-18", "stance": "warn", "quote": "it is much easier to get yourself into a bad state with git-lfs than vanilla git", "excerpt": "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 m", "context": "", "use_case": "large file storage in git", "switched_from": "", "story": "Epic Games announces Lore version control system"}]}], "who": [], "tags": [], "use_cases": ["large file versioning", "large binaries in game dev", "versioning large files", "unity project version control", "large files in git", "versioning binary data"], "compared": [{"slug": "lore", "name": "Lore", "co": 4, "switched_from": 0, "switched_to": 0}, {"slug": "perforce", "name": "Perforce", "co": 3, "switched_from": 0, "switched_to": 0}, {"slug": "git", "name": "Git", "co": 3, "switched_from": 0, "switched_to": 0}, {"slug": "git-annex", "name": "git-annex", "co": 2, "switched_from": 0, "switched_to": 0}], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=49603265", "title": "Version control second coming", "mentions": 3}, {"url": "https://news.ycombinator.com/item?id=48571081", "title": "Epic Games announces Lore version control system", "mentions": 3}, {"url": "https://news.ycombinator.com/item?id=49420598", "title": "Walgit \u2013 a Git server that is one binary in front of an object store", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49336358", "title": "Version Control for Everything", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49095865", "title": "KOReader", "mentions": 1}], "sentiment_by_month": {"2025-11": {}, "2025-12": {}, "2026-01": {}, "2026-02": {}, "2026-03": {}, "2026-04": {}, "2026-05": {}, "2026-06": {"warn": 3}, "2026-07": {"neutral": 1}, "2026-08": {"warn": 1, "recommend": 1}, "2026-09": {"recommend": 1, "warn": 1}, "2026-10": {}}, "quotes": [{"id": 794438752, "item_id": 49652422, "url": "https://news.ycombinator.com/item?id=49652422", "by": "MindSpunk", "date": "2026-09-11", "stance": "warn", "quote": "I've found LFS very brittle when bouncing between branches and moving around in history.", "excerpt": "> Git and P4 are not meant to be directly competitive here. True, but for the problems that Git LFS solves P4 is usually the other option. P4 handles large binaries very well, caveat being the rest of P4. In some projects the caveats are worth it. I work in video games and our in house engine has an unfiltered checkout size over a 1TB. I've found LFS very brittle when bouncing between branches and moving around in hi", "context": "works in video games with a 1TB repo", "use_case": "large binaries in game dev", "switched_from": "", "story": "Version control second coming"}, {"id": 794244112, "item_id": 49640257, "url": "https://news.ycombinator.com/item?id=49640257", "by": "MindSpunk", "date": "2026-09-10", "stance": "warn", "quote": "Git LFS is extremely brittle and will break your local check out if you so much as breath on it wrong", "excerpt": "From my experience Git LFS is extremely brittle and will break your local check out if you so much as breath on it wrong. Perforce is an expensive solution to the problems of LFS, and I've yet to find a workflow as powerful as my git workflows for managing code. I don't really see what the article is talking about as the future, but if P4 or Git LFS is the best we can do as a species then we're doomed. All VCS option", "context": "", "use_case": "versioning large files", "switched_from": "", "story": "Version control second coming"}, {"id": 794232608, "item_id": 49639538, "url": "https://news.ycombinator.com/item?id=49639538", "by": "bob1029", "date": "2026-09-10", "stance": "recommend", "quote": "I use git+lfs for unity projects and it works out great.", "excerpt": "It sounds like the author went through a lot of pain to avoid using git+lfs or perforce. I use git+lfs for unity projects and it works out great. If I had a real studio I'd buy some perforce seats. Reinventing the wheel like this is quite exhausting. There are options that are proven to work. AI authorship does not fundamentally violate the idea of some thing owning a specific commit. We don't need new schemas in our", "context": "", "use_case": "Unity project version control", "switched_from": "", "story": "Version control second coming"}, {"id": 790896065, "item_id": 49431004, "url": "https://news.ycombinator.com/item?id=49431004", "by": "lionkor", "date": "2026-08-25", "stance": "recommend", "quote": "There's Git LFS, that hooks up an object store (like S3) to git for large files.", "excerpt": "I struggle very much to understand the \"why\". There's a git server, it's installed when you install git, and it really does work very well. > every instance is a disposable cache that revalidates with one conditional GET. No database, no Redis, no gossip, no leader, no node identity. Git famously doesn't use that either...? What is the point? > \"just put the repositories on NFS\" failed at every large host that tried ", "context": "", "use_case": "large files in git", "switched_from": "", "story": "Walgit \u2013 a Git server that is one binary in front of an object store"}, {"id": 790155936, "item_id": 49384746, "url": "https://news.ycombinator.com/item?id=49384746", "by": "cfjgvjh", "date": "2026-08-21", "stance": "warn", "quote": "I tried using LFS as well but it didn't work for my specific workflow.", "excerpt": "I really really want to do version control for everything, but most of my data is binary so it really doesn't agree with git; I tried using LFS as well but it didn't work for my specific workflow. Hopefully something less text oriented comes along in the future. Lore looked interesting for this purpose. https://github.com/EpicGames/lore", "context": "", "use_case": "versioning binary data", "switched_from": "", "story": "Version Control for Everything"}, {"id": 785617025, "item_id": 49101064, "url": "https://news.ycombinator.com/item?id=49101064", "by": "idoubtit", "date": "2026-07-29", "stance": "neutral", "quote": "My ebooks directory uses Git (with LFS) so I can update it from several computers.", "excerpt": "> - I literally endure calibre because that's how I feed koreader. Any alternatives? I use USB mass storage. In details, I configured KOReader not to start mass storage automatically, so I need two taps after connecting the USB. Then on my Linux PC, I mount the device, exec a `rsync` command, then umount. My ebooks directory uses Git (with LFS) so I can update it from several computers. I considered switching to git-", "context": "", "use_case": "versioning ebook library", "switched_from": "", "story": "KOReader"}, {"id": 777337200, "item_id": 48583575, "url": "https://news.ycombinator.com/item?id=48583575", "by": "zipy124", "date": "2026-06-18", "stance": "warn", "quote": "it is much easier to get yourself into a bad state with git-lfs than vanilla git", "excerpt": "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 m", "context": "", "use_case": "large file storage in git", "switched_from": "", "story": "Epic Games announces Lore version control system"}, {"id": 777188848, "item_id": 48574303, "url": "https://news.ycombinator.com/item?id=48574303", "by": "Marsymars", "date": "2026-06-17", "stance": "warn", "quote": "we used Git LFS for a bit, but foud it unworkably clunky", "excerpt": "> One thing I don't like about Git LFS is that there is no way to delete very old history. It's the 'git spirit' to not allow deleting history, but in the context of LFS it sounds horrible. Especially if you use Github. At my dayjob we used Git LFS for a bit, but foud it unworkably clunky - we eventually found it easier to just make a separate \"LFS\" repository and add it as a submodule to the main monorepo. Now we ca", "context": "", "use_case": "large file versioning", "switched_from": "Git LFS", "story": "Epic Games announces Lore version control system"}, {"id": 777149745, "item_id": 48571859, "url": "https://news.ycombinator.com/item?id=48571859", "by": "penciltwirler", "date": "2026-06-17", "stance": "warn", "quote": "The premise is that Git-LFS sucks", "excerpt": "The premise is that Git-LFS sucks, so we need to build a new data versioning system (in Rust, from scratch). While I mostly agree with this premise, but there are already lots of existing (mature) data versioning systems with the same tricks under the hood: - Pachyderm (Go): https://github.com/pachyderm/pachyderm - XetHub (acquired by HuggingFace): https://huggingface.co/blog/xethub-joins-hf - LakeFS (Go): https://gi", "context": "", "use_case": "large file versioning", "switched_from": "", "story": "Epic Games announces Lore version control system"}]}