gitx is flooding/drowning my system with ls-files processes. Why?

[ikzelf]

I can understand to have a few processes doing their work but not a growing number and certainly not over 100 of them. It brings my mbp effectively to a halt. The processes are children of the gitx app and when I quit the app, the processes keep running, until I gently put them in an eternal sleep using kill -9. I will be happy to supply more info if needed. Also, I am pretty new to git so errors from my side are very possible. I am tracking certain directories in my $HOME/. Most directories are untracked (Documents, Downloads ...)

[tiennou]

Can you check that disabling the "Watch for changes in repository" settings in Preferences makes it saner ? I suspect that with a repository in $HOME, each time another process accesses it causes a refresh and thus the behavior you're seeing.

[ikzelf]

It happens where there is hardly any activity. What I did not expect was the growing number of processes. That should be limited by a sane number (max # of cores).
What I did to fix this was adjusting the .gitignore_global file so there are a few thousand files less to track and that helps making things responsive again too.

[tiennou]

Good to hear you've found a workaround. Have you been able to confirm that the issue is fixed by disabling the watcher ? But thinking about it, it seems what I propose and your workaround effect mostly the same part of the code. FYI, I have the watcher disabled here, because it has a tendency to sometime completely bork interactive rebasing (e.g. you'd end up on a step with no changes), so I'm living with manual ⌘R for the time being.

[ikzelf]

I renamed the .gitignore_global and disabled the "Watch for changes in repository". When I browsed though the repository, the # processes still shows a growth. Currently up to 20, 14 when I started typing this message so I will quickly put back my .gitignore_global to restore usability,

[tiennou]

Thanks for the additional info. I'll try to investigate what could cause such an explosion of processes. As a clarification, you meant above that the impacted git repository sits in $HOME (e.g. $HOME/.git), but doesn't contain most directories. I imagine you're doing that to track dotfiles, right ?

[ikzelf]

Yes, de repo is in $HOME. Without the .gitignore_global there are many thousands of files to track, where I want just a few hundred. And indeed, quite a few settings files living as hidden files that I also want to track. FWIW: in the same situation SourceTree did not even return at all.

[tiennou]

I've been able to reproduce, only using git. For reference, the ls-files call we do is here, in the code that refreshes our representation of the index : https://github.com/rowanj/gitx/blob/master/Classes/git/PBGitIndex.m#L513
What causes the problem is the --others options (which is used to show untracked files in GitX) ought to recurse into everything, so a call that takes less than 1 second ends up not finishing at all if you add that option. So the only viable workaround is what you're doing, adding ignore patterns in .gitignore or .git/info/exclude.

[rowanj]

Interesting; I think there's still a bug here, we should at least be killing the older process when a new one is spawned, or blocking new ones until the old ones finish.