Allow user to filter the files view to only show untracked files

[jesseduffield]

This handles the situation where the user's own config says to not show untracked files, as is often the case with bare repos managing a user's dotfiles.

• PR Description

• Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go generate ./...)
• Code has been formatted (see here)
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
• Docs have been updated if necessary
• You've read through your own file changes for silly mistakes etc

[jesseduffield]

@stefanhaller assigning you as a reviewer

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for 31e54ea1	✅ 100.00%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (31e54ea)	Report Missing	Report Missing	Report Missing
Head commit (7e85cdd)	52536	45507	86.62%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#4226)	63	63	100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

Footnotes

1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct. ↩

[stefanhaller]

Code looks great; I tested it, works great too.

One thing I find slightly confusing is how the code comments, commit message, and PR description all talk about bare repos. This is confusing because bare repos don't have a working copy, so the concept of untracked files doesn't make sense to them. Unless you use them with the --work-tree option, as described in that Atlassian blog. So I don't know, either include a link to that tutorial wherever you mention bare repos, or omit the reference to bare repos. But feel free to leave as is if you don't think it's a problem.

My remaining comments are unrelated to this PR, just noticed them while testing:

• It's unfortunate that we don't seem to display which filter is active anywhere. I'd expect to see something like (only untracked) on the right side of the Files tab's frame, like we do for (ignoring whitespace) in the main view. (Looks like this is very easy to do, so might as well include it in this PR?)
• The filter dialog could also display which filter is active, using the radio button widgets we introduced for the sort order.
• The fact that we cache git configs is annoying for testing. I typed git config status.showUntrackedFiles false while lazygit was running, and was confused that it didn't make a difference, until I remembered that we cache git configs. I ran into this before in other cases, and I do wonder if the slight performance gain that we get from caching is worth it compared to this confusion.

[stefanhaller]

I made a new PR (#4230) that sits on top of this one that addresses the first two bullet points of my comment above.

[jesseduffield]

One thing I find slightly confusing is how the code comments, commit message, and PR description all talk about bare repos. This is confusing because bare repos don't have a working copy, so the concept of untracked files doesn't make sense to them. Unless you use them with the --work-tree option, as described in that Atlassian blog. So I don't know, either include a link to that tutorial wherever you mention bare repos, or omit the reference to bare repos. But feel free to leave as is if you don't think it's a problem.

Interesting point. From what I've seen, anybody interacting with a bare repo with lazygit is typically using a worktree somewhere. E.g. with dotfiles (#1201) or when adding individual worktrees (#3100). Bare repos without worktrees are typically just remotes, and most remotes are managed by github, gitlab, etc. So I think talking about untracked files with bare repos is fine.

The fact that we cache git configs is annoying for testing. I typed git config status.showUntrackedFiles false while lazygit was running, and was confused that it didn't make a difference, until I remembered that we cache git configs. I ran into this before in other cases, and I do wonder if the slight performance gain that we get from caching is worth it compared to this confusion.

Hmm, indeed. It would be good to test the actual performance gain and if it's marginal we should definitely stop caching. It would simplify the code too. I've added an issue: #4240