Azure DevOps has recently extended support for Git Partial Clone to all its users. Partial clones represent a streamlined version of git clones initiated through specific command line arguments. Repositories that employ partial clones have demonstrated an average reduction of 88.6% in cloning time. Partial clones offer improved performance compared to traditional clones, particularly benefiting large repositories.
Highlighting the potential speed advantages for building pipelines with the use of partial clones, Michael Carlson, principal software engineer at Microsoft, provided additional details in a blog post. Unlike traditional clones, partial clones don't retrieve every historical object in the repository during the initial clone. Instead, they postpone the download of numerous objects until the checkout of a branch or other git scenarios requiring them.
The design of the Partial Clone feature aims to enhance Git's capability to manage large repositories. In the case of extremely large repositories, the cloning process can span hours (or even days) and occupy over 100 gigabytes of disk space. Often, these repositories contain numerous unnecessary blobs and trees for the user. Files may exist beyond the user's designated working area in the tree, or there may be substantial binary assets in the form of large files.
Partial clone avoids pre-emptive downloading of unnecessary objects during clone and fetch operations, resulting in reduced download times and decreased disk usage. Subsequently, missing objects can be fetched on demand when required. A remote capable of supplying these missing objects is referred to as a promisor remote, as it commits to delivering the objects upon request.
Git Partial Clone only impacts Git clones/fetches that include these specified arguments:
Blobless clones: git clone --filter=blob:none <url>
Treeless clones: git clone --filter=tree:0 <url>
Carlson called out Partial Clone feature may appear similar to the Shallow Clone feature in Azure DevOps:
git clone --depth=1 <url>
However, Shallow clones are typically used in specific scenarios, like a build pipeline that doesn't need historical context. This leads to a flattened git commit history, displaying only commits up to a certain point without awareness of previous history.
The tech community responded to this announcement by participating in the comments section of the blog post and on Reddit. One of the participants, Emil Eriksson, inquired about the compatibility of Git Partial Clone with Azure DevOps Server 2022 and whether any upgrades are necessary. Carlson replied that this feature will be available in a future release of Azure DevOps Server. On a Reddit post, a feature request was made to include treeless / blobless clones in the standard checkout task. A Microsoft staff member acknowledged this request and mentioned that they would explore the possibility of adding this feature.