--- title: The L is for looooooooooser | daily.dev description: A developer explains why storing large binary blobs in Git bloats repo history, and critiques Git LFS as painful to set up, especially in unusual mirrored-repo... canonical: https://daily.dev/posts/the-l-is-for-looooooooooser-mezqd9ytu twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: The L is for looooooooooser | daily.dev og:description: A developer explains why storing large binary blobs in Git bloats repo history, and critiques Git LFS as painful to set up, especially in unusual mirrored-repo... og:url: https://daily.dev/posts/the-l-is-for-looooooooooser-mezqd9ytu og:image: https://api.daily.dev/og/posts/mezqd9yTu.png og:image:alt: The L is for looooooooooser og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # The L is for looooooooooser **[sphaerophoria](https://daily.dev/sources/sphaerophoria)** · 20 min read · 9 upvotes · 0 comments ## Summary A developer explains why storing large binary blobs in Git bloats repo history, and critiques Git LFS as painful to set up, especially in unusual mirrored-repo workflows involving bare repos and GitHub mirrors. As an alternative, they demo a homegrown approach using unrelated git commits (via git worktrees and tagged refs) to store versioned asset blobs that are only pulled on-demand by the build system via git archive, keeping the main commit history small without requiring LFS or extra tooling for repo consumers. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why shouldn't I commit large binary files directly into a git repository? Because git pulls every version of every file from every past commit by default, so a large binary blob (like a 100MB trained model) that gets modified repeatedly will bloat the repository's history to gigabytes, even if only the latest version is needed. This makes cloning and pulling the repo slow and wasteful over time. _Developers weighing git storage tradeoffs can find deeper technical discussions like this one on daily.dev._ ### What is a practical alternative to Git LFS for storing large assets without bloating git history? One approach is to commit large asset files as separate, unrelated commit trees tagged with version names (like assets-v1, assets-v2), created using git worktree pointed at custom refs instead of branches. These asset commits are not pulled by default during a normal clone, but can be fetched on demand at build time using git archive to extract just that version's tarball, then unpacked into a build cache. This avoids requiring every contributor to install and configure a separate LFS tool. _Engineers designing their own asset-versioning workflow can compare approaches like this on daily.dev._ ### What are the downsides of using Git LFS for large file storage? Git LFS requires every person who clones the repository to separately install the LFS program and run an install command to set up git filters for their user account, which adds friction for contributors. It also becomes complicated in non-standard git setups, such as mirroring a bare repo between a local host and GitHub, where configuring where LFS should upload and download auxiliary files is unclear and can conflict across remotes. _Teams debating LFS versus alternatives for large repo assets can track these tradeoffs on daily.dev._ ## Similar posts on daily.dev - [I accidentally created a gamedev tool by implementing Git Large File Storage](https://daily.dev/posts/i-accidentally-created-a-gamedev-tool-by-implementing-git-large-file-storage-ddv4zd8qk) · Tigris · 1 upvotes · 0 comments - [Git Isn't a Diff Tracker: How Blobs, Trees, DAG Commits, and the Index Actually Work Under the Hood](https://daily.dev/posts/git-isn-t-a-diff-tracker-how-blobs-trees-dag-commits-and-the-index-actually-work-under-the-hood-pjxu9s1ep) · DEV · 4 upvotes · 0 comments - [I made my own git](https://daily.dev/posts/i-made-my-own-git-fwqs5dx1b) · Hacker News · 77 upvotes · 4 comments - [Epic Games Announces Lore Open-Source Version Control System](https://daily.dev/posts/epic-games-announces-lore-open-source-version-control-system-xafa8zvp2) · Phoronix · 4 upvotes · 0 comments - [You probably don’t need git worktrees](https://daily.dev/posts/you-probably-don-t-need-git-worktrees-ystacsb32) · RUBYLAND · 1 upvotes · 0 comments --- Tags: [#git](https://daily.dev/tags/git), [#version-control](https://daily.dev/tags/version-control), [#zig](https://daily.dev/tags/zig), [#build-systems](https://daily.dev/tags/build-systems) [View this post on daily.dev](https://daily.dev/posts/the-l-is-for-looooooooooser-mezqd9ytu) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"The L is for looooooooooser","url":"https://daily.dev/posts/the-l-is-for-looooooooooser-mezqd9ytu","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/the-l-is-for-looooooooooser-mezqd9ytu"},"datePublished":"2026-08-22T00:41:23.512Z","dateModified":"2026-09-13T21:47:42.437Z","description":"A developer explains why storing large binary blobs in Git bloats repo history, and critiques Git LFS as painful to set up, especially in unusual mirrored-repo...","image":"https://i.ytimg.com/vi/6_eCqKn9gN4/sddefault.jpg","thumbnailUrl":"https://i.ytimg.com/vi/6_eCqKn9gN4/sddefault.jpg","isAccessibleForFree":true,"articleSection":"sphaerophoria","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"sphaerophoria","logo":"https://media.daily.dev/image/upload/s--dgPUg2T7--/f_auto/v1728806109/logos/sphaerophoria","url":"https://daily.dev/sources/sphaerophoria"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/the-l-is-for-looooooooooser-mezqd9ytu","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":9},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"git,version-control,zig,build-systems","timeRequired":"PT20M","video":{"@type":"VideoObject","name":"The L is for looooooooooser","description":"A developer explains why storing large binary blobs in Git bloats repo history, and critiques Git LFS as painful to set up, especially in unusual mirrored-repo...","thumbnailUrl":"https://i.ytimg.com/vi/6_eCqKn9gN4/sddefault.jpg","uploadDate":"2026-08-22T00:41:23.512Z","duration":"PT20M","url":"https://api.daily.dev/r/mezqd9yTu","embedUrl":"https://www.youtube.com/embed/6_eCqKn9gN4"}} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"sphaerophoria","item":"https://daily.dev/sources/sphaerophoria"},{"@type":"ListItem","position":3,"name":"The L is for looooooooooser"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/the-l-is-for-looooooooooser-mezqd9ytu#faq","mainEntity":[{"@type":"Question","name":"Why shouldn't I commit large binary files directly into a git repository?","acceptedAnswer":{"@type":"Answer","text":"Because git pulls every version of every file from every past commit by default, so a large binary blob (like a 100MB trained model) that gets modified repeatedly will bloat the repository's history to gigabytes, even if only the latest version is needed. This makes cloning and pulling the repo slow and wasteful over time. Developers weighing git storage tradeoffs can find deeper technical discussions like this one on daily.dev."}},{"@type":"Question","name":"What is a practical alternative to Git LFS for storing large assets without bloating git history?","acceptedAnswer":{"@type":"Answer","text":"One approach is to commit large asset files as separate, unrelated commit trees tagged with version names (like assets-v1, assets-v2), created using git worktree pointed at custom refs instead of branches. These asset commits are not pulled by default during a normal clone, but can be fetched on demand at build time using git archive to extract just that version's tarball, then unpacked into a build cache. This avoids requiring every contributor to install and configure a separate LFS tool. Engineers designing their own asset-versioning workflow can compare approaches like this on daily.dev."}},{"@type":"Question","name":"What are the downsides of using Git LFS for large file storage?","acceptedAnswer":{"@type":"Answer","text":"Git LFS requires every person who clones the repository to separately install the LFS program and run an install command to set up git filters for their user account, which adds friction for contributors. It also becomes complicated in non-standard git setups, such as mirroring a bare repo between a local host and GitHub, where configuring where LFS should upload and download auxiliary files is unclear and can conflict across remotes. Teams debating LFS versus alternatives for large repo assets can track these tradeoffs on daily.dev."}}]} ```