[HiFiveJazz]

Summary

Avoid full repo refreshes after successful push, pull, and fetch operations when only a subset of the model can have changed.

Instead:

• push refreshes:
  • local branches
  • remote-tracking branches
  • remote metadata
  • pushed/unpushed commit status
• pull uses a targeted streaming refresh
• pull avoids redundant remote tag queries after the remote update
• fetch refreshes only:
  • branches
  • commits
  • remotes
  • tags
• background auto-fetch reuses the same targeted fetch refresh when refs change

Fetch-and-checkout and unrelated remote operations keep the existing full refresh behavior where HEAD/worktree state may have changed.

Why

Remote operations often set needs_refresh = true, which schedules a full repo refresh, which is expensive especially on big projects that use git like the Linux Kernel, leaving a lot performance to be desired.

The goal here is to keep the existing Git CLI architecture, but make refreshes operation-specific instead of blindly reloading the whole model.

Benchmarks

All Linux kernel measurements below were taken against the same checkout/configuration using strace.

Push

Using a local repo as the push target so the benchmark mostly isolates lazygitrs refresh work:

Metric	Before	After	Improvement
Git commands after push	26	5	80.8% fewer
Remote tag queries after push	2	0	eliminated
Post-push refresh latency	~1.97 s	~17.8 ms	~111× faster
Push-to-settled latency	~2.11 s	~141 ms	~14.9× faster

This optimizes the refresh work performed after git push completes.

Pull

The targeted pull refresh reduced the post-pull command set from:

Metric	Before	Targeted pull	Improvement
Git commands after pull	28	22	21.4% fewer
Traced post-pull refresh	~1.43 s	~1.14 s	~20.4% lower
Pull-to-last-refresh-child	~1.80 s	~1.53 s	~15.3% lower

The improvement comes from avoiding unrelated model reloads afterward.

The follow-up tag optimization also removes the remote tag discovery work that still remained in the targeted pull path:

• git remote
• one git ls-remote --tags <remote> per configured remote

With three configured remotes, that removed another 4 Git commands from the traced operation, though there are more ways to optimize pull still that I'm looking into.

Fetch

The targeted fetch path refreshes only branches, commits, remotes, and tags.

Metric	Before	After	Improvement
Git commands after fetch	28	8	71.4% fewer
Remote tag queries	3	0	eliminated
Median post-fetch refresh latency	~1.46 s	~772 ms	~47.2% lower / ~1.90× faster
Median fetch-to-settled latency	~1.53 s	~907 ms	~40.9% lower / ~1.69× faster

The raw git fetch itself is unchanged; this measures the refresh work
performed after it completes.

Background Auto-fetch

When periodic auto-fetch reports that refs changed, it now reuses the same targeted fetch refresh instead of scheduling a full model refresh.

This reduces recurring background work while lazygitrs is left open.

Correctness

• pull retains the existing commit filtering and unpushed-status behavior
• fetch-and-checkout keeps the full refresh path because it may change HEAD/worktree state
• added regression coverage for targeted push, pull, fetch, and auto-fetch refresh behavior
• full test suite passes
• cargo fmt --check passes
• git diff --check passes