Repeatedly hitting index.lock failures #5906

Activity

1. edhgoose

   added

   bugSomething isn't workingSomething isn't working

   on Aug 7, 2026
2. dariogliendo commented on Aug 27, 2026

   

   dariogliendo

   on Aug 27, 2026

   More actions

   Same happening for me in a large repo. I get this message in almost every single command I try to run. In my case I think it's related with using the "nvim-fugitive" plugin for neovim, which I suspect is very active with git stuff as lazygit is. I have not checked fugitive's codebase tho, so I'm just guessing.
3. edhgoose commented on Aug 29, 2026

   

   edhgoose

   on Aug 29, 2026

   Last edited by edhgoose

   Author

   More actions

   As per #5981 - I think this should resolve the issue:

   git config --global status.showUntrackedFiles normal (Globally)
   git config status.showUntrackedFiles normal (for this specific repo)

   The raised PR hopefully fixes it for everyone 🤞
4. stefanhaller commented on Aug 31, 2026

   

   stefanhaller

   on Aug 31, 2026

   Collaborator

   More actions

   @edhgoose This doesn't make sense to me, for two reasons:

   • It only happens to work in your particular scenario because for your repo the time for git status --untracked-files=all happens to be above the retry threshold, but git status --untracked-files=normal happens to be below it. That is not necessarily true for other repos; I made an extremely huge one for testing, where =all takes ~15s and =normal takes ~10s, so in that repo your fix doesn't help.
   • The user experience is unacceptable. If you create a new directory with a new file in it, how would you stage that? It would require some new feature where you can override the =normal on demand so that you see the new file (a bit like typing git add newdir/newfile manually). I don't want to invest in adding such functionality. Or it would have to be opt-in for users who know they will never need to add new files to their repo; but that opt-in already exists, it's the git config.

   What we should do next is find out if it is lazygit itself that causes the error for you guys, or some other app running in the background.

   1. Lazygit itself: with the huge test repo mentioned above I can easily reproduce the error by not waiting long enough. When I focus the lazygit terminal window it makes a refresh involving a git status call, and if I don't wait those 10s (or 15s depending on the config), the next lazygit command like staging a file shows the error. The same happens when performing a lazygit command (e.g. press space to stage a file) and then not waiting long enough before performing the next one. Please try (both of you) if you can still reproduce the error when waiting long enough after bringing lazygit to the front, and between actions.
   2. Other programs: I'm just guessing here, but I can imagine git clients that use a file watcher to get notified of when they need to refresh their UI (Sublime Merge is an example of that), and then make git status calls without GIT_OPTIONAL_LOCKS=0. If they manage to start that call before lazygit makes its own post-command refresh, and that status takes longer than lazygit's ~1.2s retry interval, then this would totally explain the error. So if you are running git clients that you suspect could play a role here (e.g. fugitive or Goland), try quitting them and see if you can still reproduce the error.

   As for possible solutions: of course 1. is unacceptable, users shouldn't have to wait between commands to avoid errors. A simple improvement could be to simply increase the retry interval; bailing out on an index.lock that is genuinely stale (e.g. after a git process crashed) is a one-time thing where users have to delete the file, and I'd say it doesn't matter too much if that error appears after 1s or 5s. A more thorough solution could be for lazygit to track its own foreground status calls (after a focus-in or after a command), and wait for them instead of handling these through the normal retry loop heuristic. That requires a little more code, but may well be worth it.

   For 2.: if we do indeed find one that is responsible, the only thing to do there is to report an issue to them to suggest adding GIT_OPTIONAL_LOCKS=0 (or --no-optional-locks) to their background status calls. Nothing we can do on our side to fix that, except for increasing the retry threshold.
5. edhgoose commented on Sep 13, 2026

   

   edhgoose

   on Sep 13, 2026

   Author

   More actions

   Hi @stefanhaller - thanks for your detailed reply. Sorry for the very slow response - I've not had time to focus on this issue.

   Regarding your questions:

   • No, I do not experience the problem if I wait. If I ensure the UI has updated to show my action is completed before attempting another action, then I do not trigger the index lock. If I try and rapid fire add multiple files, then I do experience the issue.
   • I experience the locking problem without any other git tools (my primary tool is Goland) running. I do have Sublime installed, but not with Sublime Merge. My research shows no other git processes running, except for the git fsmonitor--daemon.

   With your large repo - do you have the setting feature.manyFiles turned on? I've realised that's automatically turned on for me at my workplace, which in turn activates the core.untrackedCache. I think the key difference I'm seeing between the --untracked-files=all and --untracked-files=normal is that all can't / doesn't use the untrackedCache, which is why the performance difference is so stark. It's sub second for normal and multi-second for all.

   I've turned these settings (feature.manyFiles and core.untrackedCache) off, as well as the suggested showUntrackedFiles normal change recommended from the comment above, and removed the cache index:

   git config set core.untrackedCache false
   git config set feature.manyFiles false
   git config unset status.showUntrackedFiles
   
   # Ensuring the cache is removed:
   git update-index --no-untracked-cache
   
   time git status --untracked-files=normal --porcelain -z --find-renames=50%
   0.38s user 1.69s system 89% cpu 2.312 total
   
   time git status --untracked-files=all --porcelain -z --find-renames=50%
   0.39s user 1.62s system 108% cpu 1.856 total
   

   You can see the timing is pretty similar.

   Then turning the untrackedCache back on to confirm the difference is stark again:

   git config set core.untrackedCache true
   
   # Populate the cache:
   time git status --untracked-files=normal --porcelain -z --find-renames=50%
   0.44s user 1.83s system 106% cpu 2.133 total
   
   time git status --untracked-files=normal --porcelain -z --find-renames=50%
   0.20s user 0.25s system 119% cpu 0.376 total
   

   The time taken is significantly lower for normal.

   And now with all:

   time git status --untracked-files=all --porcelain -z --find-renames=50%  
   0.38s user 1.71s system 107% cpu 1.938 total
   
   # Again to prove it's not just a cache warmup problem:
   time git status --untracked-files=all --porcelain -z --find-renames=50%
   0.39s user 1.67s system 107% cpu 1.916 total
   

   Regarding your suggestion for lazygit to wait for its other commands to finish, I think the challenge with that is that the experience for the user could still be very poor if the UI doesn't allow interaction or update between those actions. i.e. at the moment if you undertake several actions (e.g. adding multiple files), the UI hangs while the actions block waiting for the command to retry.

   I wonder if instead of the feature changes, a better solution would be some documentation on recommended git settings for working with large repos? Which I think is to turn on these settings in git:

   Well documented elsewhere on using large repos:

   git config feature.manyFiles true
   

   Override the default lazygit behaviour for untracked-files all, which has the downside of a poor UX for adding new directories as shown below but should otherwise improve performance:

   git config status.showUntrackedFiles normal
   

   I don't perceive the UX to be too poor - it only affects files added to new directories:

   This is the default behaviour with all:
   

   This is the behaviour with showUntrackedFiles normal:

   The files within the new directory don't show (but the file within the existing directory does):
   

   And when you add the directory, the files show:
   

   There's obviously a downside if you don't wish to add the whole folder - but I don't personally mind. May be up to personal opinion!