dirty_tree: handle mixed real-vs-stat-stale modifications #76

New issue

Closed

opened 2026-05-23 20:55:31 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-05-23 20:55:31 +00:00

Owner

Originally filed by @coilysiren on 2026-04-28T06:11:09Z - https://github.com/coilysiren/repo-recall/issues/24

🤖 Filed by Claude Code on Kai's behalf.

Follow-up to #22. The fix in 9081124 handles the all-stat-stale case: if git diff --quiet exits 0, drop every modified entry as phantom. But it doesn't handle the mixed case - some entries are real diffs, some are phantom. There git diff --quiet exits non-zero (because of the real entries) and we keep the full count, including the phantoms.

Real-world example from ~/projects/coilysiren/infrastructure on kai-server: 12 entries flagged modified, 3 are real (chmod 100644 -> 100755 on three .sh launchers), 9 are phantom-dirty (no diff output, git update-index --really-refresh doesn't auto-resolve - probably CRLF / autocrlf / .gitattributes filter / filemode trust on a fresh-mounted volume). Today the dashboard says "12 modified files action required" when only 3 are real.

Fix: enumerate the real ones with git diff --name-only (and maybe git diff --cached --name-only for staged), build a set, and only count modified entries whose path is in the set. Phantoms drop both from the count and from the path sample.

Code site: same worktree_snapshot in src/commits.rs that #22 touched. Replace the all-or-nothing unstaged_diff_is_empty check with a real_modified_paths set lookup.

Cost: one extra subprocess per repo with modified entries (git diff --name-only). Same magnitude as the git diff --quiet already added.

Out of scope: detecting why a file is phantom-dirty (CRLF vs filemode vs filter). That's a debugging tool, not a dashboard signal.

🤖 Filed by Claude Code on Kai's behalf.

_Originally filed by @coilysiren on 2026-04-28T06:11:09Z - [https://github.com/coilysiren/repo-recall/issues/24](https://github.com/coilysiren/repo-recall/issues/24)_ > 🤖 Filed by Claude Code on Kai's behalf. Follow-up to #22. The fix in [9081124](https://github.com/coilysiren/repo-recall/commit/9081124) handles the *all-stat-stale* case: if `git diff --quiet` exits 0, drop every modified entry as phantom. But it doesn't handle the **mixed case** - some entries are real diffs, some are phantom. There `git diff --quiet` exits non-zero (because of the real entries) and we keep the full count, including the phantoms. Real-world example from `~/projects/coilysiren/infrastructure` on kai-server: 12 entries flagged modified, 3 are real (chmod 100644 -> 100755 on three .sh launchers), 9 are phantom-dirty (no diff output, `git update-index --really-refresh` doesn't auto-resolve - probably CRLF / autocrlf / .gitattributes filter / filemode trust on a fresh-mounted volume). Today the dashboard says "12 modified files action required" when only 3 are real. Fix: enumerate the real ones with `git diff --name-only` (and maybe `git diff --cached --name-only` for staged), build a set, and only count modified entries whose path is in the set. Phantoms drop both from the count and from the path sample. Code site: same `worktree_snapshot` in `src/commits.rs` that #22 touched. Replace the all-or-nothing `unstaged_diff_is_empty` check with a `real_modified_paths` set lookup. Cost: one extra subprocess per repo with modified entries (`git diff --name-only`). Same magnitude as the `git diff --quiet` already added. Out of scope: detecting *why* a file is phantom-dirty (CRLF vs filemode vs filter). That's a debugging tool, not a dashboard signal. > 🤖 Filed by Claude Code on Kai's behalf.

coilysiren added the

label

2026-05-31 01:54:58 +00:00

coilysiren added

and removed

labels

2026-06-04 08:16:38 +00:00

coilysiren commented

2026-06-17 08:24:23 +00:00

Author

Owner

Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag: burndown-2026-06.

Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag: `burndown-2026-06`.

coilysiren

2026-06-17 08:24:23 +00:00