Bug Report: Persistent False Unstaged File Count

Gitstatus Bug Report: Persistent False Unstaged File Count

Summary

Gitstatus consistently reports 96 unstaged files in a large Android repository (22k tracked files, 235k total) even when git correctly reports 0 modified files. The false count persists across daemon restarts, cache deletions, and survives for weeks.

Environment

• OS: macOS (Darwin, Apple Silicon M1/M2)
• Gitstatus version: v1.5.4 (Feb 14 2022)
• Shell: zsh 5.9
• Accessed via: Powerlevel10k theme
• Git version: Latest

Repository Details

• Tracked files: 21,988
• Total files (before cleanup): 235,055 (including 212,937 in build/ directories)
• Total files (after cleanup): 25,488
• Type: Android Gradle project with 176 modules
• Git index size: 4.1 MB

Bug Description

Symptoms

1. Opening a fresh terminal in the repository shows !96 in prompt
2. Running git status or git diff-files correctly shows 0 modified files
3. After pressing Enter (which triggers prompt refresh), it shows !0 or no indicator
4. The variable $VCS_STATUS_NUM_UNSTAGED contains 96 on initial query
5. The number !96 grows along time
6. This issue does NOT occur in a similar iOS repository (16k tracked, 18k total files)

Reproduction Steps

1. Navigate to large Android repository with many build artifacts
2. Ensure no actual changes: git status shows clean
3. Open new terminal in that directory
4. Observe gitstatus reports 96 unstaged files
5. Run any command - next prompt refresh shows correct 0

What We've Tried (All Failed)

• ✗ Killed all gitstatus daemons (multiple times)
• ✗ Deleted all cache directories (~/.cache/p10k*, ~/.cache/gitstatus)
• ✗ Ran git update-index --refresh
• ✗ Ran git status (fixes it, but only for that session)
• ✗ Disabled/enabled git optimizations (fsmonitor, untrackedCache, splitIndex)
• ✗ Cleared instant prompt caches
• ✗ Disabled instant prompt entirely
• ✗ Added hooks to run git status before gitstatus queries
• ✗ Cleaned all build directories (removed 212,937 files, reduced from 235k to 25k total files) - Issue persists!

What DOES Work

• Running git status fixes the display for subsequent prompts in that session
• Opening a new terminal shows the false count again

Theory

The "96" appears to be:

1. NOT from instant prompt cache (persists with instant prompt off)
2. NOT from current git state (git correctly reports 0)
3. NOT from current file count (persists after removing 212k build files)
4. Possibly accumulated "racily-clean" index entries from historical Gradle builds
5. Cached in gitstatus daemon binary or undiscovered persistent storage
6. Triggered by repository characteristics (large module count, historical build activity)
7. Related to repository complexity - doesn't happen in smaller iOS repo

Expected Behavior

Gitstatus should report 0 unstaged files when git status reports no changes.

Actual Behavior

Gitstatus reports 96 unstaged files on every new shell, despite no actual changes.

Additional Context

• The zsh version of gitstatus plugin doesn't expose -r (repo-ttl-seconds) parameter that exists in bash version
• Default TTL is 3600 seconds (1 hour)
• Suspicion: gitstatus daemon stores state in compiled binary or undiscovered location
• Critical: Issue persists even after removing all 212,937 build files
• Critical: Issue persists across complete cache deletions and daemon restarts
• The "96" value appears to be from historical build activity, not current state
• Likely related to large multi-module Android/Gradle project structure (176 modules)

Comparison Data

Metric	Android App (HAS BUG)	iOS App (NO BUG)
Tracked files	21,988	16,630
Total files (before clean)	235,055	17,933
Total files (after clean)	25,488	17,933
Build files removed	212,937	N/A
Issue after cleanup	STILL YES	NO
Gradle modules	176	N/A

Feature Request

1. Expose -r (repo-ttl-seconds) parameter in zsh plugin
2. Fix persistent state that survives daemon restarts
3. Consider ignoring stat-only mismatches without content changes
4. Add debug logging option to trace where cached values come from

Investigation Notes

• 2 days of extensive debugging
• 30+ solutions attempted
• Root cause: Persistent cached value in gitstatus daemon that survives:
  • All cache deletions
  • Daemon kills and restarts
  • File removal (cleaned 212k files)
  • Git index refresh operations
• The false count shows even with 0 actual git changes
• The value appears to be stored in a location inaccessible through standard troubleshooting
• Possibly stored in: compiled binary state, kernel cache, filesystem metadata, or undiscovered persistent storage

---

Generated: October 7, 2025
Reporter: Community investigation via Powerlevel10k users

Start with the gitstatus daemon and zsh plugin entry points, reproducing the initial prompt query in the described large Android repository while comparing it with git status. Trace where the unstaged count is obtained and persisted across daemon restarts and cache deletion; done means identifying the source of the stale value and defining a reproducible regression check.