Pushing A-->B needs an active component in B to update indexes if B is user facing #1589

git-bug version: v0.10.1

Setup:

Two local clones of the same git-bug-tracked repo, A and B. All writes happen in A via the git-bug CLI (e.g. git-bug bug status close ), followed by a plain git-bug push from A to B (a normal git push of refs/bugs//refs/identities/; no git-bug command is ever run inside B as part of this).

Observed in B, after the push completes:

• git bug bug show — correctly reflects the new status (e.g. closed).
• git bug bug (bare list command, no subcommand) — still reports the old status (e.g. open) for that same bug, consistently, across repeated invocations.
• .git/git-bug/cache/bugs's mtime is confirmed (via stat) to predate the bug ref's mtime at the time of the stale read, and is not touched by running bug show or bug again.
• Deleting .git/git-bug/cache/ entirely and letting git-bug rebuild it from scratch immediately produces the correct list output.

Expected:

git bug bug should reflect the current state of a bug's ref regardless of whether the update arrived via a local git-bug write or via an external git push/git-bug push from another clone.

Possibly related:

#235 (termui shows stale bug status, closed in 0.6.0) describes a very similar list-vs-show discrepancy, but in a single-repo/same-session scenario (local write, then immediately viewed in the same termui session) rather than a cross-repo push scenario. If the original fix only addressed same-session cache invalidation, this may be an unhandled adjacent case rather than a true regression — flagging the connection in case it's useful for narrowing down the cache-invalidation logic.

Happy to provide a minimal repro script (two local repos + a short sequence of git-bug CLI calls) if useful.