Summary
When the suite clone is on a detached HEAD, whitaker-installer runs git pull, which fails — but the installer exits 0 and continues, building and installing the lint suite from the stale revision. It then repoints the whitaker wrapper's DYLINT_LIBRARY_PATH at that stale build, replacing a working install with a broken one and giving no indication anything went wrong.
Reproduction
Observed on a machine where ~/.local/share/whitaker was detached at 692f654 (v0.2.6-5-g692f654), 31 commits behind main. Running whitaker-installer:
+ 754f2aa...5e52aa5 lint-candidates -> origin/lint-candidates (forced update)
You are not currently on a branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.
git pull <remote> <branch>
That is the entire tail of the log. Exit code: 0.
The fetch succeeds, the merge step fails, and the run proceeds to build from the stale checkout.
Impact
The failure is not cosmetic, because a stale suite does not degrade gracefully. NoStdFsConfig is #[serde(default, deny_unknown_fields)], so a suite predating dbc930a ("Add module-path suppression to no_std_fs_operations") does not merely ignore excluded_paths — deserialization of the whole [no_std_fs_operations] table fails and every exclusion is dropped, including excluded_crates entries the old suite does support.
In leynos/netsuke this turned make lint red repo-wide, flagging build.rs, build_l10n_audit.rs and other long-excluded paths, with 9 no_std_fs_operations errors. The symptom presents as a repository problem, so the diagnosis path is long: the config, the lint policy and the changed code all look guilty before the tooling does. Filed separately as the graceful-degradation half of this.
Verified by swapping only the library, same tree and command:
| Suite build |
std::fs errors |
built from main (has dbc930a) |
0 |
built from 692f654 |
9 |
Suggested fixes
- Fail the run (non-zero exit) when the repository update step fails, rather than continuing with a stale checkout.
- Handle a detached HEAD explicitly — either check out the intended ref, or refuse with a clear message naming the current revision and the expected one.
- Do not repoint the wrapper's
DYLINT_LIBRARY_PATH until a build has been produced and verified, so a failed run leaves the previous working install intact.
Note on how it became detached
The clone also carries an issue-271-ref-pinned-installation branch, so the detached checkout plausibly originated from the ref-pinning work in #271. Whatever the cause, the installer should not treat a detached HEAD as a silently-successful update. This is orthogonal to #271: pinning decides which ref to install, this issue is that a failed update reports success.
Environment
whitaker-installer from ~/.cargo/bincargo-dylint 6.0.1- toolchain
nightly-2026-05-28
- Linux (Rocky 10)
Summary
When the suite clone is on a detached HEAD,
whitaker-installerrunsgit pull, which fails — but the installer exits 0 and continues, building and installing the lint suite from the stale revision. It then repoints thewhitakerwrapper'sDYLINT_LIBRARY_PATHat that stale build, replacing a working install with a broken one and giving no indication anything went wrong.Reproduction
Observed on a machine where
~/.local/share/whitakerwas detached at692f654(v0.2.6-5-g692f654), 31 commits behindmain. Runningwhitaker-installer:That is the entire tail of the log. Exit code: 0.
The fetch succeeds, the merge step fails, and the run proceeds to build from the stale checkout.
Impact
The failure is not cosmetic, because a stale suite does not degrade gracefully.
NoStdFsConfigis#[serde(default, deny_unknown_fields)], so a suite predatingdbc930a("Add module-path suppression tono_std_fs_operations") does not merely ignoreexcluded_paths— deserialization of the whole[no_std_fs_operations]table fails and every exclusion is dropped, includingexcluded_cratesentries the old suite does support.In
leynos/netsukethis turnedmake lintred repo-wide, flaggingbuild.rs,build_l10n_audit.rsand other long-excluded paths, with 9no_std_fs_operationserrors. The symptom presents as a repository problem, so the diagnosis path is long: the config, the lint policy and the changed code all look guilty before the tooling does. Filed separately as the graceful-degradation half of this.Verified by swapping only the library, same tree and command:
std::fserrorsmain(hasdbc930a)692f654Suggested fixes
DYLINT_LIBRARY_PATHuntil a build has been produced and verified, so a failed run leaves the previous working install intact.Note on how it became detached
The clone also carries an
issue-271-ref-pinned-installationbranch, so the detached checkout plausibly originated from the ref-pinning work in #271. Whatever the cause, the installer should not treat a detached HEAD as a silently-successful update. This is orthogonal to #271: pinning decides which ref to install, this issue is that a failed update reports success.Environment
whitaker-installerfrom~/.cargo/bincargo-dylint6.0.1nightly-2026-05-28