Summary
Follow-up to #531. Now that GitSync honors an arbitrary clone depth at clone/obtain() time, the update path could optionally deepen or unshallow an existing checkout when the requested depth differs from what's on disk (mirroring Git.fetch(depth=..., deepen=..., unshallow=...)).
This was split out of #531 because it carries edges and policy questions that warrant their own design, rather than blocking the core clone-depth feature.
Edges to handle
git fetch --depth N against a full (non-shallow) checkout silently truncates it to a shallow N-commit repo — history loss if applied unconditionally on every update. The update path must not shrink a full repo.git fetch --unshallow against a complete repo is a fatal error, so unshallow must be guarded by git rev-parse --is-shallow-repository.- git exposes whether a repo is shallow but not its current depth, so "depth changed" needs a proxy (commit count /
.git/shallow) — define the intended semantics explicitly.
Open questions
- What should
depth=None mean for an existing shallow checkout — leave as is, or unshallow?
- Should a numeric
depth ever be allowed to shrink a fuller checkout, or only deepen?
Acceptance
update_repo() honors self.depth on already-cloned repos without history loss on full checkouts.- Tests cover: shallow→deepen, shallow→unshallow, full→update (no shrink).
Summary
Follow-up to #531. Now that
GitSynchonors an arbitrary clonedepthat clone/obtain()time, the update path could optionally deepen or unshallow an existing checkout when the requesteddepthdiffers from what's on disk (mirroringGit.fetch(depth=..., deepen=..., unshallow=...)).This was split out of #531 because it carries edges and policy questions that warrant their own design, rather than blocking the core clone-depth feature.
Edges to handle
git fetch --depth Nagainst a full (non-shallow) checkout silently truncates it to a shallow N-commit repo — history loss if applied unconditionally on every update. The update path must not shrink a full repo.git fetch --unshallowagainst a complete repo is a fatal error, so unshallow must be guarded bygit rev-parse --is-shallow-repository..git/shallow) — define the intended semantics explicitly.Open questions
depth=Nonemean for an existing shallow checkout — leave as is, or unshallow?depthever be allowed to shrink a fuller checkout, or only deepen?Acceptance
update_repo()honorsself.depthon already-cloned repos without history loss on full checkouts.