perf: prevent repeated status fetches in large repos

[DannyStoll1]

This PR fixes/closes #2823

It changes the following:

• Remove tick from StatusParams hash
• Add generation counter that increments after each fetch completes
• Include generation in cache hash

This ensures:

• No repeated fetches while one is already pending, making gitui usable in very large repos
• New fetch starts immediately after completion, keeping gitui responsive in small repos
• External file changes will still be detected on the next fetch cycle

I followed the checklist:

• No added unittests: the change is a behavioral fix to existing code, and the existing tests pass
• I ran make check without errors
• I tested the overall application: on my 1.7M file target repository, load time goes from 5+ minutes to ~2.5 seconds
• I added an appropriate item to the changelog

[extrawurst]

Oh wow interesting, I wonder when we broke that. Great find

[cruessler]

Thanks for the PR (and the accompanying issue)! I’ll try to have a look over the weekend!

[cruessler]

@DannyStoll1 From what I can tell, these lines seem to serve the same purpose:

gitui/asyncgit/src/status.rs

Lines 95 to 98 in 7747d82

	if self.is_pending() {
	log::trace!("request blocked, still pending");
	return Ok(None);
	}

Am I missing something? Do you happen to know why they haven’t prevented gitui from becoming slow in your case?

[DannyStoll1]

Apologies for the delay getting back to you on this.

is_pending() does block ticks that arrive during a fetch, but it doesn't prevent the problem because of the interaction between the millisecond-granularity tick and the 5-second UI tick interval.

For instance, this is the event sequence for a single AsyncStatus instance in a large repo where a fetch takes ~13 seconds:

T=0s:   Tick -> fetch(tick=T0)   -> pending=false -> hash=H0 -> MISS -> spawn -> pending=1
T=5s:   Tick -> fetch(tick=T5)   -> pending=true  -> BLOCKED
T=10s:  Tick -> fetch(tick=T10)  -> pending=true  -> BLOCKED
T=13s:  task completes           -> pending=0
T=15s:  Tick -> fetch(tick=T15)  -> pending=false -> hash=H15 (!= H0!) -> MISS -> spawn -> pending=1
T=20s:  Tick -> fetch(tick=T20)  -> pending=true  -> BLOCKED
T=25s:  Tick -> fetch(tick=T25)  -> pending=true  -> BLOCKED
T=28s:  task completes           -> pending=0
T=30s:  Tick -> fetch(tick=T30)  -> MISS -> spawn again...

Tick is in milliseconds, meaning the hash is always different on the first tick after completion, guaranteeing a cache miss and a new spawn. So is_pending() correctly blocks intermediate ticks, but the cycle never terminates -- every completion is followed by exactly one re-fetch.

This PR tries a different solution: the hash would only change when a fetch completes, so the very next tick after completion gets a miss and starts a new fetch, but ticks that arrive while pending are blocked to prevent queue buildup.

The behavior is the same for small repos -- the difference is that the cache invalidation is tied to completion rather than wall clock time, so there's no risk of the hash silently changing between "pending=0" and the next tick.