Repository navigation
Index is refreshed when chunks and files are staged -- is this neccessary? #428
Description
I've been trying to understand why gitx wheel spins, sometimes for a few seconds, with Refreshing index... whenever something is staged, and have found:
- Index refresh is done by spawning an external task:
git update-index -q --unmerged --ignore-missing --refresh. - The refresh is invoked in
PBGitCommitControllerwhen it sees repository updated events of typeWorkingDirandIndex. In this case it is the Index event that is responsible for the refresh. - These events are sent by
PBGitRepositoryWatcher. - The Index event is generated when the index directory's modification time is changed.
Given that gitx should be able to determine if all of an un-staged file has been staged (and vice-versa) and so update the appropriate lists, is there a need to then refresh the index?
#181 is related.
Activity
dbrnz commentedon Jan 1, 2024
Hmm, with a bit more testing I understand that the index refresh is needed...
Why though the wheel spin? Is it because of lock contention?
Commenting out line 126 of
PBGitCommitController.mto disable refresh when staged and then usingCmd-Rto manually refresh results in a fast refresh, as does runningupdate-index --refreshfrom the command line, so does the refresh need to be deferred until after the stage/un-stage has finished processing?hannesa2 commentedon Mar 17, 2026
Is this now solved with https://github.com/gitx/gitx/releases/tag/1.4 ?
test: characterize staging refresh edge cases
Publish coherent index snapshots and reset paths from parent
Coalesce stage diff rendering after index updates
test: ratchet staging index coverage
Report coherent index snapshot counts accurately
test: ratchet verified staging coverage
Document runtime logging verification policy
goneng commentedon Sep 18, 2026
Fixed by #547.
The
git update-index -q --unmerged --ignore-missing --refreshspawn you traced no longer runs on the Index and WorkingDir events. It moved to-applicationDidBecomeActive:, so it happens once when the app comes to the front rather than on every FSEvents notification. Staging now takes the internal path only, which isls-files,diff-indexanddiff-files, and never takesindex.lock.To your actual question, whether the refresh is needed at all: it is still wanted, but for a narrower reason than it was being used for. It clears phantom "modified" entries where content matches but mtime does not, which the app cannot work out for itself. Running it once per activation covers that without the contention.
One thing that did not change: the status bar still reads "Refreshing index..." during the internal refresh, so the old wording can still suggest the old behaviour. Worth a separate issue if it is still misleading in practice.