gitui crashes with too many untracked files

[glaeqen]

Describe the bug
This problem becomes an issue when attempting to use gitui together with tools like vcsh. VCSH is a git wrapper that uses "fake" bare git repositories that set a root in a home directory. Thus, one can modularize system configuration by having multiple repositories with a root at $HOME.

Trying to run gitui through vcsh run <repo_name> gitui (this sets GIT_DIR accordingly) results in a crash because it tries to render all untracked files in the home directory.

To Reproduce
Steps to reproduce the behavior (without vcsh):

1. Run

DIR="/tmp/some-test-bare-repo.git"
git init --bare "$DIR" && \
GIT_DIR="$DIR" GIT_WORK_TREE="$HOME" gitui

Note: $HOME has to be big enough to cause the crash. Otherwise, any other directory with huge amount of files pointed to by $GIT_WORK_TREE could be used.

2. Crash

Expected behavior
Crash caused by immense amount of files is probably very difficult to solve. Nonetheless some kind of workaround would be nice. For example, similarly to git status --untracked-files=no, a new flag for gitui could make it ignore all the untracked files. Feel free to suggest the solution though :)

[glaeqen]

I initially commented at #1223, FTR

[glaeqen]

I just realized that even with .gitignore.d/<repo> set to ignore everything but checked in files, gitui crashes with

Error: receiving on an empty and disconnected channel

[extrawurst]

can you try running with --polling?
see #1444

[glaeqen]

Yey, it helped! Although running vcsh write-gitignore <repo> was necessary to make irrelevant part of the $HOME dir invisible for git . Otherwise gitui starts choking on files. But does not crash! Thanks

[extrawurst]

How exactly does it behave when you say “choking on files”? Even with the polling arg?

[glaeqen]

Well, working directory is in $HOME. So it takes a minute or so to even list the files that are untracked. It's just a lot of files.

If all untracked files are ignored, it is pretty much instantaneous.

[extrawurst]

should be fixed in the next release via #1444