[Feature Request] Not to show files listed in `.git/info/exclude`

[chenrry666]

Just as the title, maybe gitu could respect .git/info/exclude and not to show them in the file tree. Since I'm trying to use gitu to manage my dotfiles, listing every file in $HOME is not a good choice: have to wait for a couple of seconds that gitu could respond to user input.

Lazygit has this feature, but it seems to use the git command directly under the hood (I haven't read its code though.), so it might not be a proper reference.

[altsem]

Hi!

I think it already does this. Could you provide some steps to reproduce the problem? I might've misunderstood, or else I suspect there's an issue regarding submodules or something.

gitu on  altsem/value-arguments ❯ cat .git/info/exclude
# git ls-files --others --exclude-from=.git/info/exclude
# Lines that start with '#' are comments.
# For a project mostly in C, the following would be a good set of
# exclude patterns (uncomment them if you want to use them):
# *.[oa]
# *~
invisible.txt

gitu on  altsem/value-arguments ❯ git status
On branch altsem/value-arguments
Your branch is up to date with 'origin/altsem/value-arguments'.

nothing to commit, working tree clean

gitu on  altsem/value-arguments ❯ touch visible.txt invisible.txt
gitu on  altsem/value-arguments [?] ❯ git status
On branch altsem/value-arguments
Your branch is up to date with 'origin/altsem/value-arguments'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        visible.txt

nothing added to commit but untracked files present (use "git add" to track)

And in gitu:

▌On branch altsem/value-arguments
▌Your branch is up to date with 'origin/altsem/value-arguments'.

 Untracked files
 visible.txt

 Recent commits
 99a75bb altsem/value-arguments origin/altsem/value-arguments refactor: explicitly close `pending_menu`, access args from prompts
 4cb8b25 test: refactor src/tests/log, test grep/limit "other"
 eb26e0a Add more tests
 691b815 fix snapshots
 1d1d7c5 Fix value_as::<T>()
 994cfd3 rename get_args to init_args
 c70ebc3 refactor: extract type alies for set_prompt's `default_fn`
 439474c refactor: run `cargo clippy --fix`
 44d0f48 refactor: remove requirement of `clone` for Args
 5a61344 Add tests

[chenrry666]

Sorry for the late reply! Quite busy these days.

I think it already does this.

I didn't notice it, sorry for the inconvenience.

However, there is an issue of lagging when starting gitu. I've recorded a video.

https://github.com/altsem/gitu/assets/40446983/dec68589-b676-42e8-8c90-fdb1444d6bc9

Take my dotfiles repo for an example, there is \~150 modified files, and \~40 untracked files, Starting Lazygit is fast, but when it comes to gitu, have to wait for 1\~2s. As you can see, there is about 100 lines of exclude in my .git/info/exclude. So probably there is some other performance related issues? But it might be another issue.

[altsem]

@chenrry666 No worries! Hmmm. I tried just creating a bunch of random files and listing them doesn't seem to take too long time. It's hard to tell from the video, but I'm guessing that filtering actually does fail.

Gitu is using libgit2 to retrieve the status. I found this open issue about the .gitignore (could be related?): https://github.com/libgit2/libgit2/issues/6250

It'd be interesting to know more about your dotfiles setup. Which OS are you on? Do you use worktrees or is the repo a submodule? Are the files not being ignored symlinks?

[chenrry666]

I am using Arch Linux. The dotfiles repo isn't bare repo, so it is using worktree. The files are correctly ignored, sorry I didn't mention that.

The issue is that the lagging before the TUI being drawn may relate to some performance issues. Maybe the filtering process causes the lagging, IMO.

[altsem]

Alright. It could be like you say. And the code is indeed not quite optimized and will try render everything (even though they're not shown).

How many files is it? I think git status --porcelain | wc -l would answer it :)

[chenrry666]

I couldn't reach my laptop in two weeks at the moment. 🫠 It was sent for repair just this afternoon. Hence I could't provide more details in a short time.

I do remember there is more than 40k files in my $HOME (including yarn cache, crates, etc.) so it is probably where the lagging comes from. 🥲

[chenrry666]

Luckily I am able to come back. Here are the results:

❯ git status --porcelain | wc -l
70
❯ find . -type f |wc -l
163871

Much files here :cold_sweat: but git has correctly ignored it.