Commit view should auto-refresh, independently of auto-fetch

[glasser]

Is your feature request related to a problem? Please describe.

I often make commits to my repo outside of lazygit. Notably these days, these commits are often made by my Claude Code, and I'm using lazygit to see the changes CC has made.

While the files view auto-refreshes at refreshInterval to show uncommitted changes, the commits list does not refresh that frequently. It only refreshes downstream of fetching from upstream (fetchInterval), which probably should be a less frequent operation as it's a remote operation rather than local.

It would be nice if locally-made commits showed up in the commits view independently of the slower remote fetch.

Describe the solution you'd like

The refresh done at refreshInterval refreshes the commits view, or some other opt-in setting to sets a commits-specific refresh interval.

Describe alternatives you've considered

Set fetchInterval to be 10 seconds instead of 60 — much more network/API usage.

I would be happy to contribute a PR to add commits refresh to the standard refreshInterval if that's a design you'd support.

[stefanhaller]

It only refreshes downstream of fetching from upstream

The "only" here is not true: lazygit also refreshes its commits view when its terminal window becomes active again, on the assumption that if you make commits outside of lazygit it must be in a different terminal tab, or a different application altogether (IDE). The case that an agent makes commits in the background while lazygit is active is new and we didn't consider it.

I'm not sure I like the idea of a timer-based auto-refresh, but then I don't have a great idea what else we can do. I'll think about it some more.

[glasser]

Hmm, what's the definition of active terminal window?

I've been running lazygit within zellij (similar to tmux/screen) in a split pane situation where I have lazygit in one pane and something else (a shell, Claude Code, etc) in the other one. So lazygit is visible but maybe it's not "active"? I see the edited files diff changing in the "background" (side pane) but not the commits list. Or alternatively, maybe Claude is doing work in the background while lazygit is active, as you say.

It does feel to me like it shouldn't be that inefficient to check if HEAD has changed? Surely compared to the full git status equivalent (which involves checking the entire working tree) checking what commit is at HEAD is fast?

[stefanhaller]

Hmm, what's the definition of active terminal window?

That's up to the terminal to decide, I guess. The ones that I'm using send focus events even when you switch between tabs in the active window; if tmux or zellij don't do this, I'd personally call that a bug, but I don't think there's any spec that demands this.

It does feel to me like it shouldn't be that inefficient to check if HEAD has changed?

That would still require a git call though (we can't just read .git/HEAD), and there are some other challenges with implementing this properly. Not saying it can't be done, it's just not trivial, and I'm not sure yet how many users are affected by this so that it's worth spending time on.

[glasser]

I guess as maybe a simpler request, could an explicit R refresh refresh the commit view too?

[stefanhaller]

I guess as maybe a simpler request, could an explicit R refresh refresh the commit view too?

It does. The problem with the R keybinding is that it isn't available in all panels; in the branches and commits panels there are local commands bound to R that override it. We need a solution for this at some point; my own workaround is to rebind Refresh to = which is unused and works in all views.

keybinding:
  universal:
    refresh: =

[glasser]

I think I need to actually have the commits panel highlighted for that to work? I guess intuitively I just expected there to be a button to press (or timer to set up) that means "make everything I'm looking at refreshed", not just the panel I have highlighted. But this is definitely a step in the right direction for me, thanks!

[stefanhaller]

No, the refresh key refreshes everything, independent of which panel you're in. If it doesn't for you, let me know, then we may have a bug somewhere.

[stefanhaller]

Ah -- if you use = like I suggested, it doesn't work in the files panel, because the key is used for something else there. Bad suggestion, sorry.

[rcdailey]

@stefanhaller I want to be upfront about a few things before diving in. I've read the CONTRIBUTING guidance and I respect your position on PRs. I also use AI-augmented development (Claude Code, specifically). My workflow involves direct human review and collaboration on every change, but I realize that's just words until demonstrated. I'm not here to push a PR; I just want to share an approach that might be worth considering, and offer to help if you'd find it useful.

Filesystem watch instead of polling

You mentioned not liking the idea of a timer-based auto-refresh, and the concern about unnecessary git calls. I think there's an approach that avoids both: watching the filesystem for ref changes rather than polling.

When a commit is made, git updates a small set of known files:

• .git/refs/heads/<branch> (branch tip moves via lock-then-rename)
• .git/HEAD (branch switch or detached HEAD)
• .git/packed-refs (after git pack-refs or gc)

A filesystem watcher on those paths would give instant detection with zero cost when idle. No git commands run until something actually changes.

Implementation sketch:

Go has a mature cross-platform library for this: github.com/fsnotify/fsnotify. It supports Linux (inotify), macOS (kqueue), Windows (ReadDirectoryChangesW), BSD (kqueue), and illumos (FEN), which covers all platforms lazygit ships on. Requires Go 1.23+ (lazygit is on 1.25).

The watcher would monitor:

• .git/refs/heads/ as a directory (catches branch tip updates; fsnotify recommends watching the parent directory for atomically-replaced files, which is how git updates refs)
• .git/HEAD (via watching .git/ and filtering)
• .git/packed-refs (same)

On any event, debounce for ~150ms (to coalesce multi-file operations like rebase), then trigger a refresh of COMMITS + BRANCHES + REFLOG.

fsnotify doesn't watch subdirectories on any platform, but that's fine here since we only need a few specific paths.

Considerations:

• Worktrees: .git can be a file pointing elsewhere. The watcher would need to resolve the actual gitdir (lazygit already has this logic).
• Packed refs: after git gc, branch refs may live only in .git/packed-refs rather than individual files. Watching that file covers the case.
• Reftable backend: Git 3.0 will make reftable the default for new repos. With reftable, refs aren't stored as individual files; they're in binary tables under .git/reftable/, with a tables.list manifest that changes on every ref update. The watcher would need to detect which backend is in use and adapt (watch tables.list instead of refs/heads/). Not a blocker for the initial implementation since the files backend is still dominant, but worth designing for.

Why this might work better than a timer:

• Zero overhead when nothing changes (which is most of the time)
• Sub-second detection when something does change
• No git commands fired speculatively
• Users who make commits externally (agents, scripts, other terminals) get immediate feedback

I'm happy to prototype this and share results as a branch or gist you could evaluate on your own time. Let me know if this is an approach you'd be interested in exploring, or if there are concerns I'm not seeing.

[stefanhaller]

@rcdailey I did consider using fsnotify myself, but I like it even less. The main reason is that I don't want to depend on git's internals; another reason is that debouncing can be tricky. You mention a debounce period of 150ms, but that may well be too small for large repos. Yet another reason is that it's tricky to prevent the watcher from kicking in for the changes that are caused by lazygit's own commands.

For all these reasons I went with polling after all; a PR is here: #5662. I'm very interested in feedback, especially on the question whether it should be on by default (currently yes, but I'm not sure that's good), and about the default polling interval (currently 2s, not sure that's a good compromise between timely updates and low CPU usage).