fix: pin --untracked-files so status.showUntrackedFiles cannot hide work [patch]

[matt-edmondson]

Fixes #112

What was wrong

GitStatusBuilder added --untracked-files=<mode> only when a caller had called WithUntrackedFiles(...). With no such call the vector was just git status --porcelain=v2 --branch -z, and git then resolves the mode from status.showUntrackedFiles — a variable a minimal CI image or a developer's ~/.gitconfig can set to no to keep git status fast in a large tree.

Reproduced against git 2.43, the version the issue reports:

$ git status --porcelain=v2 --branch          # default config
# branch.oid 56f00a4dfe66a7f0f90c067ce0e1ee791d9fd268
# branch.head main
? untracked.txt

$ git config status.showUntrackedFiles no
$ git status --porcelain=v2 --branch          # same working copy
# branch.oid 56f00a4dfe66a7f0f90c067ce0e1ee791d9fd268
# branch.head main

So the same repository state produced IsClean == true with an untracked file sitting in it — silently, and precisely for the caller asking "is there work here I would destroy?" before discarding a working copy.

This is the one verb that still left a host-configurable default unpinned. GitCommandBuilder.BuildArguments already pins --no-pager, core.quotepath=false and color.ui=false unconditionally, and RunCommandGitProcessRunner forces LC_ALL=C and GIT_TERMINAL_PROMPT=0, for the same reason.

The change

• GitStatusBuilder.DefaultUntrackedFiles (GitUntrackedFilesMode.Normal — git's own documented default, so nothing changes on a host that has not set the variable) initialises the field, and the flag is emitted unconditionally.
• Because the default lives in the field rather than at the emission site, WithUntrackedFiles(...) replaces it. The vector never carries two --untracked-files values, so a caller passing No does not first pay for a normal walk it declined.
• IGitStatusBuilder.WithUntrackedFiles and the class summary record the pinned default; CLAUDE.md gets design point 14 beside the other non-obvious, load-bearing choices.

GitStatusParser's doc comment is left alone: it names the output format it reads, which this flag does not change.

Tests

Builder tier (GitIntegration.Test/Builders/GitStatusBuilderTests.cs):

Test	Covers
BuildsTheDefaultStatusVector	updated — the acceptance criterion, asserting --untracked-files=normal is in the vector with WithUntrackedFiles never called
ChoosingAModeReplacesThePinnedDefaultRatherThanJoiningIt	new — exactly one --untracked-files= argument, and it is the caller's; the hazard an unconditional default introduces

Integration tier (GitIntegration.Test/Integration/GitRoundTripTests.cs), which is where a config-resolution bug can actually be caught:

• StatusReportsUntrackedWorkEvenWhereTheHostHidesItAsync — sets status.showUntrackedFiles = no in the throwaway repository's own config (the same variable resolved from the nearest scope, so the test neither depends on nor disturbs the runner's global config), then asserts Status() still reports IsClean == false and an entry for the untracked file. It closes by asserting WithUntrackedFiles(No) still reports clean, so the test cannot pass by the builder simply ignoring the caller.

Verification

• dotnet build and dotnet build -c Release: 0 warnings, 0 errors.
• KTSU_GIT_INTEGRATION_TESTS_REQUIRED=1 GIT_CONFIG_NOSYSTEM=1 dotnet test: 590 passed, 0 failed, 0 skipped — integration tier exercised rather than skipped, and GIT_CONFIG_NOSYSTEM=1 set per CLAUDE.md so the POSIX path is what ran.
• Mutation-checked by substitution, per CLAUDE.md: restoring the nullable field and the if (_untrackedFiles is GitUntrackedFilesMode mode) guard fails exactly BuildsTheDefaultStatusVector and StatusReportsUntrackedWorkEvenWhereTheHostHidesItAsync (2 failed / 588 passed). ChoosingAModeReplacesThePinnedDefaultRatherThanJoiningIt passes either way, as a guardrail on behaviour this change must not disturb. The tree was re-verified against a pre-mutation copy afterwards, and the full suite re-run green.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WVrdn7dcoGasLJEgrnb67u

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[matt-edmondson]

Notes on the two CI signals above, so neither needs chasing down:

SonarCloud's remaining "1 New issue" is MSTEST0054 at GitIntegration.Test/Integration/GitRoundTripTests.cs:164 — Use TestContext.CancellationToken instead of TestContext.CancellationTokenSource.Token, INFO severity, gate passed.

It is left as-is deliberately. The older form is this suite's universal idiom — roughly 250 call sites across 32 files — and it is flagged here only because the line is new. Changing this one line would make it the sole outlier in the repository rather than fixing anything. If the newer property is wanted, it is a suite-wide sweep of its own, not a drive-by in a fix PR.

The other three findings from the first analysis were real and are fixed (Assert.ContainsSingle and Assert.Contains in place of the AreEqual/IsTrue forms; the fold removed the CollectionAssert.DoesNotContain call entirely).

Test on macos-latest in Cross-Platform Tests was cancelled on the first attempt, having sat for 20 minutes against a timeout-minutes: 15 budget with no uploaded logs. That was a stalled runner, not this change: the ubuntu leg of the same run passed in 55 seconds, the same macOS job passed in ~2 minutes on the previous head (which already carried the fix and the new integration test), and the same commit's macOS test passed in the templated workflow. One re-run confirmed it — 19:02:15 → 19:04:07, green.

All checks are green on dccc7a8 and the branch merges cleanly.

---

Generated by Claude Code