Shipped in 1.4
Large files, first class
Git LFS keeps big things — artwork, model weights, audio, video — out of the repository and on a server, leaving a small pointer behind. Version 1.0 spotted those pointers and refused to break them. Version 1.4 fetches them, uploads them, and tells you what they cost.
It knows what it’s looking at
The repository’s .gitattributes says which paths belong to LFS, and the pointer’s own signature proves it for anything the rules missed. Either signal is enough, so a file that’s been overwritten locally is still recognised.
Real sizes, not 130 bytes
A pointer on disk is about 130 bytes, which is useless if you’re deciding whether to pull a 200 MB asset on cellular. The pointer records the true size, so that’s what you’re shown before you spend anything.
Content when you ask for it
Nothing downloads behind your back. Ask for a file and it comes down over the LFS batch protocol into a local cache, addressed by hash — so the same object is only ever fetched once, however many branches point at it.
Content up, pointer in
Commit a large file and the content goes to the LFS server first; only then does the pointer go into the commit. That order matters — a pointer whose content never arrived is a broken repository for everyone who clones it.
The bit that goes wrong elsewhere
It won’t let you break the contract
The classic LFS accident is writing real bytes over a pointer and committing that. The binary gets buried in history and every other client sees a repository that no longer makes sense. The app treats that as a thing to prevent, not a thing to report.
oid sha256:4d7a214614ab2935c943f9e0ff69d22eadbb8f32b1258daaa5e2ca24d17e2393
size 211106232
That third line is the whole trick: 211 MB of content, standing in a file of about 130 bytes. Read it and you can tell someone what a download costs. Ignore it and you show them a 130-byte image.
Storage
Your device, your disk
Fetched content is cached per repository. Settings shows what each one is holding and gives it back on request — the pointers stay, so nothing is lost, and anything you free can be fetched again whenever you next have signal.
When it can’t
Told plainly, not as a status code
“Out of LFS quota” and “no signal” both read as download failed if you don’t bother to tell them apart — and they call for completely different responses from you. So they’re told apart: no connection, storage or bandwidth quota exhausted, sign-in no longer accepted, or the object simply isn’t on the server.
Straight about it
What LFS still costs you
Two things worth knowing before you rely on it.
The first fetch needs signal
Everything else in the app works offline. LFS content can’t, because it isn’t on the device until it’s fetched — that’s what LFS is. Afterwards it’s cached and offline like anything else.
Your host’s quota still applies
LFS storage and bandwidth are metered by whoever hosts the repository, not by the app. If GitHub says you’re out, the app says so in those words rather than pretending it was a network blip.
Included in the same one-off purchase as everything else. Get the app →