Question
Git LFS pointer storage vs standard Git objects for portable local mirrors
Sky Orbit
0 reputation · 12 Aug 2023, 03:23 UTC
55.3K views
Loading…
0 reputation · 12 Aug 2023, 03:23 UTC
A design decision is needed for a repository that contains large binary assets and must balance local disk footprint against full portability.
Standard Git object storage keeps every byte of a binary in the packfile history, which preserves a self-contained repository that can be archived and checked out offline without external dependencies. Git LFS replaces large files with text pointers in the main repository and stores the actual binary data on a separate LFS server, reducing the size of the initial clone and the local working tree footprint.
The constraint is a requirement for a fully self-contained local mirror that remains usable offline, while also limiting local disk usage for multiple versions of large binaries. The trade-off is between repository portability as a single source of truth and the performance and footprint benefits of offloading binaries.
With Git 2.x and an LFS client available, does a repository using LFS pointers satisfy the portability definition of standard Git object storage for offline archival? How does the local disk footprint compare when retaining multiple historical versions of the same large binary under each approach?
32275 reputation · 12 Aug 2023, 06:37 UTC
No. With Git 2.x and an LFS client present, an LFS-enabled repository does not satisfy the standard Git portability definition for offline archival by default.
Standard Git object storage is self-contained: the .git directory contains all blobs, trees and commits, so a clone, bundle or filesystem copy can be checked out offline with no external dependencies.
Git LFS replaces large files with small text pointers stored as normal Git objects. The binary payloads live outside the Git object database, in .git/lfs/objects and are fetched on demand via the LFS client and remote. A bare .git copy without the LFS objects directory, or a clone performed without an LFS client, yields pointer files only.
Working tree footprint: LFS is smaller. Only the version checked out for HEAD is materialized in the working tree, and the .git directory stays small because pointers are tiny.
Historical retention footprint: Standard Git retains every binary version in packfiles, so .git grows monotonically with each change.
LFS can be comparable or larger locally if the local LFS cache retains all historical versions. By default, git lfs fetch pulls objects for the current ref only. Running git lfs fetch --all or checking out old commits populates .git/lfs/objects with those versions. If you keep a full mirror, combined size of .git + .git/lfs can equal or exceed a pure Git packfile store, with the advantage that the working tree stays lean.
gitgit lfs ls-filesgit lfs fetch --allgit checkout <old-commit> then open the large file.du -sh .git .git/lfsgit lfs export workflows. A plain git bundle does not include LFS objects.Assumption: Git 2.x with git-lfs client installed and configured. Uncertainty remains if you rely on server-side LFS smudge filters only; behavior changes without the client.
Do you require the ability to checkout arbitrary historical commits fully offline without any pre-fetch step? If yes, you must either pre-populate the LFS cache for all history and ship .git/lfs with the mirror, or avoid LFS and accept packfile bloat. If you only need HEAD offline, a partial LFS cache is sufficient.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.