fix: index untracked files in graph builds

[Ha1baraA11]

Pull Request

Linked issue

Related to #998

What & why

• Include staged, unstaged, and untracked files in the working-tree fallback when the configured base ref cannot be resolved.
• Use a monorepo-root Git inventory for subproject builds and filter it to the requested subproject, keeping full and incremental builds aligned.
• Skip untracked symlinks during indexing so they do not reappear on each update.

How it was tested

• uv run ruff check code_review_graph/ — passed.
• uv run pytest tests/ --tb=short -q — 5051 passed, 880 skipped, 3 xfailed, 2 xpassed, 1 warning.
• uv run pytest tests/test_integration_git.py::test_full_build_and_update_keep_untracked_files_in_monorepo_subproject --tb=short -q — 1 passed; the same test fails on the unchanged staging base at the node-existence assertion.

Checklist

• Tests added for new functionality
• All tests pass: uv run pytest tests/ --tb=short -q
• Linting passes: uv run ruff check code_review_graph/
• Type checking passes: uv run mypy code_review_graph/ --ignore-missing-imports --no-strict-optional
• Lines are at most 100 characters
• Docs updated where behavior changed (README, docs/, docstrings)

[tirth8205]

Thank you for this PR. I tested update, build and detect-changes on real Git repos.

Before I can merge it, please fix these:

1. Unstaged edits can disappear from detect-changes. This happens when the base ref does not resolve. One example is HEAD~1 in a repo with one commit. The --cached list now includes untracked files, so it is never empty. Then discover_review_changes skips its working-tree fallback. Where: code_review_graph/incremental.py:1122. Example: one commit, edit seed.py, add new.py. Only new.py is reported.

2. Update and build disagree in a monorepo subproject (build --repo mono/module). get_changed_files lists untracked files there. collect_all_files does not, because it needs .git in the root. So update adds the file, and the next build deletes it. Where: incremental.py:1495.

3. An untracked symlink like link.py -> seed.py is indexed again on every update. Update parses it, stale cleanup removes it, then it comes back. Where: incremental.py:2053.

After you push the fix, I will test it again.

[github-actions]

code-review-graph review

Overall risk: 0.65 (MEDIUM) — 22 changed function(s)/class(es), 39 affected flow(s), 3 test gap(s) (0 with no tested caller found, 3 reached only through a caller)

Risk-scored changes

Risk	Level	Symbol	Location	Tested
0.65	medium	code_review_graph/incremental.py::detect_vcs	code_review_graph/incremental.py:355	indirect
0.60	medium	code_review_graph/incremental.py::_git_worktree_prefix	code_review_graph/incremental.py:369	indirect
0.55	medium	code_review_graph/incremental.py::get_changed_files	code_review_graph/incremental.py:1059	yes
0.55	medium	code_review_graph/incremental.py::get_staged_and_unstaged	code_review_graph/incremental.py:1263	yes
0.55	medium	code_review_graph/incremental.py::collect_all_files	code_review_graph/incremental.py:1503	yes
0.55	medium	code_review_graph/incremental.py::incremental_update	code_review_graph/incremental.py:1959	yes
0.40	medium	code_review_graph/incremental.py::_get_untracked_files	code_review_graph/incremental.py:1444	indirect
0.35	low	tests/test_failure_reporting.py::_Result	tests/test_failure_reporting.py:360	(test)
0.30	low	tests/test_failure_reporting.py::fake_run	tests/test_failure_reporting.py:357	(test)
0.05	low	tests/test_failure_reporting.py::test_a_base_ref_that_does_not_resolve_is_not_an_unrunnable_git	tests/test_failure_reporting.py:353	(test)

Affected execution flows

• process — criticality 0.74, 541 node(s) across 14 file(s)
• _run — criticality 0.74, 568 node(s) across 16 file(s)
• build_or_update_graph_tool — criticality 0.73, 622 node(s) across 24 file(s)
• refactor_tool — criticality 0.72, 159 node(s) across 12 file(s)
• main — criticality 0.72, 927 node(s) across 40 file(s)
• ...and 34 more affected flow(s)

Reached only through a caller

No test names these directly, but a tested caller reaches them along the call path shown. That is a path in the call graph, not a record of execution -- the caller's tests may never take this branch. Treat it as where to look, not as coverage: these count as gaps and are scored as untested.

• code_review_graph/incremental.py::detect_vcs (code_review_graph/incremental.py:355) — via code_review_graph/incremental.py::collect_all_files, 1 hop(s)
• code_review_graph/incremental.py::_git_worktree_prefix (code_review_graph/incremental.py:369) — via code_review_graph/incremental.py::get_staged_and_unstaged, 1 hop(s)
• code_review_graph/incremental.py::_get_untracked_files (code_review_graph/incremental.py:1444) — via code_review_graph/incremental.py::collect_all_files, 1 hop(s)

---

Powered by code-review-graph — local-first analysis; no code leaves the CI runner.