dns-server build script discards git-stub-vcs's shallow-clone diagnostic, replacing an actionable message with a Debug dump

Description

git clone --depth 1 of omicron fails to build with a message that says the
opposite of what happened and omits the fix:

thread 'main' panicked at dns-server/build.rs:10:10:
detected VCS at repo root: ShallowClone { vcs: Git, repo_root: "/opt/omicron/omicron/dns-server/.." }

Two things are wrong with that output.

The expect message reads as success. "detected VCS at repo root" describes
what the call was trying to do, and on failure it is printed as though it were a
statement of fact. A reader's first assumption is that detecting the VCS is
not the problem.

The actual remedy is thrown away. Result::expect formats the error with
Debug, not Display. git-stub-vcs has a genuinely good Display impl for
this exact case — errors.rs:

#[error(
    "shallow clone detected at {repo_root}: cannot dereference \
     git stubs without full history{}", shallow_clone_msg(.vcs),
)]
ShallowClone { vcs: VcsName, repo_root: Utf8PathBuf },

and shallow_clone_msg returns, for git:

"(run `git fetch --unshallow`)"

So the library already tells the user precisely what to do, and the build script
substitutes a struct dump for it. The information exists and never reaches the
person who needs it.

This is one line, in one file — grep -rn for_build_script --include=build.rs
returns exactly one hit in the tree.

Steps to reproduce

1. git clone --depth 1 https://github.com/oxidecomputer/omicron.git
2. cargo build --bin omicron-dev

Expected result

The panic carries the library's own message:

shallow clone detected at /path/to/omicron: cannot dereference git stubs
without full history (run `git fetch --unshallow`)

Actual result

detected VCS at repo root: ShallowClone { vcs: Git, repo_root: "..." }

The word "shallow" does appear, so a persistent reader gets there. But the
suggested command does not, and the leading clause actively misdirects.

Suggested fix

In dns-server/build.rs, print the Display form:

let materializer = Materializer::for_build_script("..")
    .unwrap_or_else(|e| panic!("{e}"));

or keep the context and chain it:

.map_err(|e| format!("initializing git stub materializer: {e}"))
.unwrap();

Either preserves the remedy. The same treatment is worth applying to the
.expect("materialized dns-server v1 git stub") immediately below it.

Workaround

git fetch --unshallow, or clone without --depth.

Environment

omicron df990b0578fbee4afcf805423a20d85e23544e0d (2026-09-04)
crate git-stub-vcs 0.1.0 (crates.io)
rust 1.98.1 (pinned by rust-toolchain.toml)
platform aarch64-unknown-linux-gnu, Ubuntu 24.04

Not architecture-specific: a shallow clone produces this on any platform.

---

Disclosure: this issue was investigated and written up with AI assistance
(Claude). Everything in it was measured rather than inferred — the timings,
error output, version numbers and reproduction steps are all from real runs on
real hardware, and where a fix is suggested it is one I am actually running. I
have read it through before filing. Happy to clarify anything or test a patch.

Start in dns-server/build.rs at the Materializer::for_build_script call and the following materialized dns-server v1 git stub expect. Reproduce with a shallow clone and cargo build --bin omicron-dev, then verify that the failure preserves git-stub-vcs's actionable Display message, including the git fetch --unshallow remedy, instead of a Debug dump.