Cargo discussion questions shallow Git clones for Rust dependencies

A Rust Internals thread filed under Cargo put an old ergonomics complaint back on the table: Git dependencies still did not have a supported shallow-clone path. The poster needed a fork of rusqlite because they rely on cksumvfs, which they said is not yet officially supported upstream, and Cargo appeared to download the full repository history instead of just the commit needed for the build.

The poster said they checked first and concluded “the answer is no for the current version of Cargo.” That made the issue less about a missing flag in one local setup and more about a gap in Cargo’s Git dependency behavior itself. For a large repository, the extra history meant a slower, heavier first fetch than the user wanted, especially in the common case where a project only needs one pinned revision.

That tradeoff is why the question keeps returning in Cargo circles. A shallow clone can cut bandwidth, disk use, and wait time for CI jobs, local experiments, and contributor workflows that just need the tip of a branch. But Cargo’s dependency model is built around reproducibility, lockfiles, and exact revisions, so a full fetch can be part of the package manager’s promise rather than an accident of implementation. The tension is between a faster checkout and a dependency graph that stays stable when metadata, branches, or commit ancestry matter.

The discussion also fit into a longer line of past Cargo work. rust-lang/cargo issue #10078, titled “Improve performance of fetching git dependencies by rev,” shows that performance concerns around Git dependencies were already on the table. Another issue, #1171, “Allow specifying shallow clones in .config,” points to an earlier request for configuration-level control. In a separate Rust Internals thread about upcoming Cargo.lock changes, the Cargo team said it was adjusting the lock-file format in preparation for fixing Git dependency behavior around default branches, another sign that this part of Cargo’s design has been under active pressure for some time.

The Cargo Book already treats Git repositories as a normal dependency source alongside crates.io, other registries, and local file system subdirectories. Its override guidance also notes that dependency overrides are commonly used when a crate needs to work with code before it is published to crates.io. That makes a forked rusqlite for cksumvfs feel less like an edge case than a textbook Git dependency workflow.

So the shallow-clone question lands in a familiar place for Rust users: a practical performance win collides with Cargo’s guarantees about exact source and repeatable builds. The use case is real, the pain is measurable, and the current answer remains the same one the poster found first.