hesela.devGit partial clone
A Git partial clone omits selected repository objects while retaining a configured promise that missing objects can be fetched when needed.
Object scope: partial clone filters objects within a selected commit graph; shallow cloning limits the history graph itself. The two mechanisms are distinct and can be combined. A provider must remain available for objects not materialized locally. [1]
Verification: Git v2.43.0 fsck recognizes promised absence. In a seven-case experiment, full and strict checks passed with five missing blobs; a HEAD checkout fetched two but left historical reads unavailable offline. One online read fetched its object and changed the candidate inventory. These are designed cases, not failure frequencies. [2] [5]
Recovery scope: rev-list --objects --all --missing=print can succeed while listing missing IDs. A shallow boundary can also hide required history without reporting missing objects. Retain the intended history scope and test a disposable copy with providers unavailable. [3] [4]
Archival boundary: self-contained objects do not establish reader compatibility. The native controls used one Git version, so cross-version restoration and external application dependencies remain untested. [5] [6]
Relations
Advantages
- Can avoid transferring file contents that are not yet needed.
Limitations
- Missing promised objects remain a dependency, not an independent backup.
Citations
- Git v2.43.0: partial-clone dependency contract
- Git v2.43.0: promisor-aware object checks
- Git v2.43.0: missing-object enumeration
- Git v2.43.0: shallow history boundaries
- Hesela: Git partial-clone offline recovery controls
- Hutchinson et al.: Logical vs. Physical File System Backup, OSDI 1999, sections 1, 3-5
Sources & caveats
- Pinned Git v2.43.0 design and implementation, plus native Git 2.43.0 controls. No later-version equivalence or hardware reliability inference.