Improving Git-LFS Clone Performance with Partial Clone
A team uses Git-LFS to store large binary files. They observe that cloning the repository takes a long time because Git-LFS files are downloaded. How can they improve clone performance?
Quick Answer
The --filter=blob:none flag turns the clone into a partial clone that skips downloading blob objects — including the large files LFS is tracking — up front, fetching only commit and tree metadata first. Git then lazily pulls the actual LFS blobs only when something in the working tree actually needs them, which is what cuts the slow initial clone down dramatically.
⚠ Common exam trap
Watch out — candidates often confuse shallow clones (which limit history) or sparse checkouts (which limit working tree files) with partial clones (which limit object downloads), not realizing that Git-LFS files are downloaded during checkout regardless of history depth or sparse patterns unless blob filtering is used.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use the --filter=blob:none option when cloning
The `--filter=blob:none` option performs a partial clone, which omits all blob objects (including Git-LFS pointer files and other large blobs) from the initial download. This significantly reduces clone time by only fetching commit and tree metadata, and then lazily downloading blobs on demand when they are actually accessed. For Git-LFS specifically, this avoids downloading the large binary files stored in LFS until they are needed, improving clone performance.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use a shallow clone with depth 1
Why it's wrong here
Shallow clone reduces commit history but still downloads LFS files for the single commit.
- ✓
Use the --filter=blob:none option when cloning
Why this is correct
This partial clone defers downloading LFS blobs until they are accessed.
- ✗
Use sparse checkout to limit files in working directory
Why it's wrong here
Sparse checkout limits checked-out files but LFS is still downloaded for all files.
- ✗
Configure git lfs prune to run automatically
Why it's wrong here
Prune removes local LFS cache but does not affect clone time.
Go deeper
Related to this question
Learn chapter
Implementing and Managing Source Control
Key term
Git
Git is a version control system that tracks changes to files so multiple people can work on the same project without overwriting each other's work.
Key term
Repository
A repository is a central storage location where software packages, code, or configuration files are kept, managed, and distributed for use by IT systems.
About these practice questions
This AZ-400 question is part of Courseiva's 823-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
2 more ways this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Your Azure DevOps repository contains a large binary file that is slowing down clone operations. Which Git feature should you use to reduce the clone time?
easy- A.Shallow clone
- ✓ B.Git LFS (Large File Storage)
- C.Depth parameter in clone command
- D.Sparse checkout
Why B: Git LFS (Large File Storage) is the correct solution because it replaces large binary files in the repository with lightweight text pointers, storing the actual binary content in external remote storage. This prevents the large file from being downloaded during every clone, significantly reducing clone time and repository size on disk.
Variation 2. Your team manages a large monorepo in Azure Repos containing multiple projects. Developers frequently complain that cloning the entire repository takes too long and that they only need a subset of the code. The team uses Git LFS for large binary files. The repository currently has 50,000 commits and is 5 GB in size. You want to improve clone performance without sacrificing the ability to contribute to any part of the repo. What should you do?
easy- A.Configure sparse checkout so developers can clone only the directories they need.
- ✓ B.Instruct developers to use a shallow clone with depth 1 to reduce clone time.
- C.Move all large binary files to Git LFS to reduce repository size.
- D.Split the monorepo into multiple repositories and use submodules to aggregate them.
Why B: Using a shallow clone with depth 1 significantly reduces clone time by fetching only the latest commit history instead of all 50,000 commits. This minimizes the data transferred over the network, which is the primary cause of slow clones. Developers can later deepen the clone if they need more history. Sparse checkout alone does not reduce the data transferred during clone; it only limits what appears in the working directory. Git LFS is already being used for large binaries, so that is not the issue. Splitting the monorepo would require significant restructuring and may complicate cross-project contributions.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.