chore: stop ignoring the tracked Cargo.lock

[rhoadesScholar]

.gitignore line 8 listed Cargo.lock, but Cargo.lock is — and always has been — tracked in this repo. The pattern was never in effect for the committed file, so this is a one-line correction of a .gitignore that stated the opposite of the repo's actual (and correct) policy.

Why keep the lockfile tracked rather than untrack it

Both halves of the contradiction could be resolved by deleting the file instead. That would be the wrong call here: publish.yaml builds release wheels for seven platform targets from the same Rust sources —

job	targets
manylinux	x86_64, aarch64
musllinux	x86_64, aarch64
windows	x64
macOS	x86_64 (macos-13), aarch64 (macos-14)

A pinned dependency graph is what makes those seven builds reproducible and comparable to each other, and what makes a release bisectable later. Cargo.lock belongs in the tree; the ignore line does not.

Why the stale line was not harmless

Git exempts files already in the index from .gitignore, which is why nothing visibly broke. Two real costs:

1. It is a false statement of intent — anyone reading .gitignore concludes the lockfile is deliberately untracked.
2. It is armed. The moment someone does git rm --cached Cargo.lock (or re-adds the file in a fresh clone path), the lockfile silently disappears from the repo with no git status entry to notice.

Verification

Chore bucket — no behaviour change, so there is no failing→passing example to show. What there is to verify is the contradiction itself and that removing the line surfaces nothing new. Verbatim, in a clean worktree off origin/v2.0 (542c3c2):

Before — the file is tracked and the repo claims to ignore it:

$ git ls-files --error-unmatch Cargo.lock
Cargo.lock
$ echo $?
0

$ grep -n 'Cargo' .gitignore
8:Cargo.lock

$ git check-ignore -v --no-index Cargo.lock
.gitignore:8:Cargo.lock	Cargo.lock

Note --no-index: plain git check-ignore Cargo.lock exits 1 and prints nothing, because git skips the ignore rules for tracked files. That exemption is exactly what hid this for so long, so --no-index is the flag that actually shows what the pattern says.

The general form of the check, which finds every tracked-but-ignored path at once:

$ git ls-files -i -c --exclude-standard
.claude/settings.local.json
Cargo.lock

(.claude/settings.local.json is not a repo-level contradiction — it is matched by my personal global ~/.config/git/ignore, not by anything in this repo. Mentioned only so the output above is not misread.)

After — file still tracked, no rule claims it, nothing new appears:

$ git ls-files --error-unmatch Cargo.lock
Cargo.lock
$ echo $?
0

$ git check-ignore -v --no-index Cargo.lock
$ echo $?
1

$ git ls-files -i -c --exclude-standard
.claude/settings.local.json

$ git status
On branch chore/gitignore-cargo-lock
Your branch is ahead of 'origin/v2.0' by 1 commit.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

The working tree stays clean because the only Cargo.lock in the tree is the tracked one at the workspace root — find . -name Cargo.lock -not -path './.git/*' returns just ./Cargo.lock, even though the workspace has two members (daisy-core, daisy-py), neither of which carries its own lockfile.

Diff

 *.egg-info/
-Cargo.lock
 
 # Sphinx build artifacts

Heads-up: trivial conflict with #72

#72 adds .vscode immediately after the Cargo.lock line, so its hunk and this deletion overlap. Confirmed, not guessed:

$ git merge-tree --write-tree --messages HEAD pr72-test
1f7e551cb58e3409e86b3164c38b80e3abe4085f
100644 52312a4e3adaa9a5b686759e1c1ee4a524d13ab5 1	.gitignore
100644 87988eb53fe888d6485728af501aa68a5a4c17e7 2	.gitignore
100644 1489b94651e37030e42ac0e7bd9bbeabca8f2018 3	.gitignore

Auto-merging .gitignore
CONFLICT (content): Merge conflict in .gitignore

Whichever lands second needs a one-line resolution: keep .vscode, drop Cargo.lock. I deliberately did not fold the .vscode addition in here to keep this PR to the single line it is about.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

[rhoadesScholar]

The conflict with #72 you flagged is already resolved — no action needed here.

I force-pushed a rebuild of #72 against current v2.0 shortly before this landed, and it dropped the .gitignore hunk entirely (the .vscode line was an unrelated rider inherited from the closed #70). #72 now touches only build_wrapper.py and two lines of pyproject.toml.

Verified just now:

$ git diff origin/v2.0 --name-only origin/jeffr/loud-fail-missing-build-tools
build_wrapper.py
pyproject.toml

$ git merge-tree <base> <#72> <#76> | grep -c '^<<<<<<<'
0

So this PR is a clean one-line deletion against v2.0 and the two can land in either order.

Thanks for catching it — and for the better diagnostic. git ls-files -i -c --exclude-standard is the right tool for this class of bug and I'll use it instead of check-ignore going forward; you're right that plain git check-ignore -v Cargo.lock prints nothing and exits 1, which is exactly the wrong signal.