Compare the whole Git workflow before replacing LFS
Git partial clone can defer binary history without LFS pointers. Check server filters, later object fetches and collaborator recovery before migrating assets.
By 
Paul. Architecture and infrastructure
A smaller initial clone is useful evidence about one step in collaboration. It is not enough evidence to replace the way a team stores large files. Git partial clone can defer downloading binary history while keeping those contents as Git objects. Choose it by examining what happens after the first checkout, including who serves missing objects and how every collaborator obtains them.
Looking back from November 2026, Tyler Cipriani's 15 August 2025 article argued that Git itself offered a path beyond LFS. His demonstration reported large improvements for repeated versions of a generated image. Those results belong to his example and conditions, not an AL+ benchmark or a speed forecast for another repository.
The two systems omit different things
The Git LFS project's explanation, consulted in November 2026, describes replacing file contents inside Git with text pointers while storing the actual contents on a separate server. That introduces a second object-delivery path. Collaborators need the LFS tooling and access to its storage, as well as access to the Git repository.
Partial clone keeps the relevant contents within Git's object model but allows selected objects to be absent locally. The versioned Git 2.49.0 design documentation, dated 14 March 2025 in the manual's history, describes filtering during clone and fetch, promisor remotes and later retrieval. A missing object can be expected because a remote has promised to provide it; absence does not automatically mean repository corruption.
This is different from shortening the commit history with a shallow clone. A client can retain the commit relationships while omitting some file contents. It is also different from sparse checkout, which selects paths in the working tree. Combining techniques may be appropriate, but each choice answers a separate question about what the collaborator needs locally.
The distinction changes migration planning. Enabling partial clone does not convert existing LFS pointers into ordinary Git blobs. A historical revision containing a pointer still contains that pointer. Any proposed conversion of historical storage is a separate operation with consequences for collaborators and recovery. This article performs no conversion or history rewrite.
Deferred transfer remains a dependency
A filter can avoid downloading old binary versions nobody needs today. Checking out a revision that needs an omitted object can then require a network fetch. That is a good trade when most contributors use a narrow part of history and the remote remains reachable. It is a different experience for someone preparing to work offline or investigating an old release during a hosting outage.
A sensible evaluation follows that second situation as carefully as the first clone. Identify the revisions people actually revisit and the tools that inspect their contents. A history view that needs only commit metadata has different requirements from an operation reading an old binary. “The history is available” should therefore specify whether it means relationships, file contents already present, or contents retrievable from a remote.
The Git clone reference, a current reference read for this retrospective, describes object filters. The server must support the required filtering path. A command accepted by a local Git client does not establish that every forge or every server configuration honors the requested filter. Check the actual endpoint and its policies before making a repository-wide recommendation.
Moving fewer bytes to each new workstation also does not erase server-side storage or hosting restrictions. Those are separate constraints. Cipriani discusses large object promisors as developing work in 2025; his future direction should not be retold as universal support already delivered by hosting providers. Current availability needs its own check against the selected host and versions.
LFS can remain the responsible choice
The strongest argument for LFS is a team whose host, asset tools and contributors already support it well. The extra delivery path may be understood, backed up and affordable. Migrating solely to remove an extension could replace known maintenance with less familiar assumptions about filters and on-demand fetching.
That does not make LFS friction imaginary. A collaborator without the extension can encounter pointer text where an asset was expected. A repository mirror that preserves Git objects alone can leave the external contents out of the recovery plan. These are reasons to inspect the full arrangement, not proof that every LFS installation is unreliable.
Partial clone has its own completeness question. A working copy that depends on future object fetches is not a complete offline archive merely because its commit graph is present. Decide which copy is intended for everyday work and which is intended for recovery. Each can be valid without pretending to serve the other's purpose.
Make one collaboration path explicit
Before migrating, describe a contributor joining, checking out an older release and producing an artifact that needs its assets. Include the automation account doing the same work in CI. These are proposed verification cases, not tests run for this article. They reveal authentication and object availability assumptions that an attractive clone timing cannot settle.
For custom software development, put asset recovery beside source recovery in the handover. Keep LFS where that arrangement is coherent; consider partial clone where native Git objects and deferred transfer better match the team's work. The decision earns its value when the second checkout and the replacement workstation are as understandable as the first clone.