Git Partial Clone Now Supported in Azure DevOps
Git Partial Clone
Treeless and blobless Git Partial Clones are now enabled in Azure DevOps for all customers! Partial clones are a reduced type of git clone that users create via specific arguments on the git command line. For large repositories with a lot of history, they offer a dramatic performance improvement compared to a regular clone, with some tradeoffs. Partial clones do not download every single historical object in the repository at clone time like a traditional clone. Instead, they delay downloading many objects until checkout of a branch (or other git scenario) that needs them. Those who want a deeper understanding of what blob and tree objects are and what this tradeoff means should read this GitHub blog post.
How To Use
This feature ONLY affects git clones/fetches that pass these arguments. Blob size limits are not yet supported, and attempting to specify those will result in the clone request failing at this time. These are the supported commands:
git clone --filter=blob:none <url>
git clone --filter=tree:0 <url>
Partial clones show a large performance benefit over traditional clones, benefitting large repositories the most. We’re seeing an average 88.6% reduction in clone time in repositories where it’s used. The very largest of those repositories enjoy a >99% reduction in clone time.
Many build pipelines may see a speed benefit from using partial clone. Also, partial clone is suitable for developer machines that need a fast clone, or need to prioritize disk space.
Partial != Shallow
At first glance this feature may seem similar to the shallow clone feature
git clone --depth=1 <url>, which Azure DevOps already supported. Although shallow clones are even faster than partial clones, they leave the user with a flattened git commit history with only the latest state of the repository. Additionally, because of the way git commit hashes work, such a repository has a different commit hash than the server knows about. Therefore, shallow clones are only useful in specific scenarios such as a build pipeline that doesn’t look at history nor the git commit hash.