Use .gitignore to hide files in explorer

[mtripp100]

Forking #23804 on the advice of @isidorn as it was conflating two issues - colouring and hiding gitignored files in the file explorer.

• Greying/colouring works great as of 1.18.
• Hiding them completely still requires an extension or manually syncing ignored patterns with the files.exclude setting.

I would love a separate setting which completely hides files instead of just greying them out. Thanks.

[derwaldgeist]

I'd like to support this. I'm coming from Atom and used to not having my .gitignored files clutter my folder structure.

[isidorn]

fyi @joaomoreno @jrieken

[tanzislam]

For the moment, if people would tolerate the use of a plugin for this, the most accurate one I know of (in terms of using relevant entries from multiple .gitignore files, wildcard entries, etc. etc.) is this one.

I've tested two other plugins, but the edge-case bugs/limitations are frankly maddening. (It matters for me because my build system dynamically writes out .gitignore files in various subdirectories and I need my editor to respect them.)

[HitomiTenshi]

• Requested on Nov 21, 2017
• Labeled on Nov 22, 2017

Today is July 29, 2018 and there is still no real answer or progress being made to support this feature.

I come from Atom as well and gave VS Code a chance. Working with TypeScript and Sass creates a bunch of compiled JavaScript and CSS files which all clutter the Explorer a lot. I guess I'll stay with Atom for a while longer.

[jsardev]

@HitomiTenshi Yeah, you had more than one year to contribute and all you do is complain 😛 I don't want to be rude but... C'mon, it's open-source, you don't pay a penny for an awesome piece of software and still demand from the team to add all the features you want. OSS is something different than this.

[HitomiTenshi]

@sarneeh You're right. But you can't expect everyone to be able to code or know the project code well enough to just quickly whip up a PR with a new feature. What if I'm just a designer proficient in HTML & CSS but bad at anything else?

Maybe my wording is a bit demanding, I just wanted to point out that there is no official answer whether this feature request will be even considered. They labeled it but I don't think they gave it any thought (yet).

[jsardev]

@HitomiTenshi When you don't have the skills or time, all you can do is be patient, wait and count on the community to add this feature 😄

I don't know if a thought from the creators/maintainers would change anything for this issue. It's just a feature request - when there's big demand on it and someone will code it - it will get reviewed and released. If not - it will hang here forever 😄

Okay! Enough of this spam here!

[HitomiTenshi]

@sarneeh Well my goal was to notify the creators/maintainers that this feature is still needed by some people. The last few comments were from January this year. If no one keeps requesting this, because they are "patient, waiting and counting on the community", then no one will know that there is a big demand for this 😉

[tanzislam]

@HitomiTenshi You did notice my suggestion about available plugins, right? It's not like people can't use the functionality right now, and that (i.e. a workaround exists) makes this issue lower priority than many others.

If you want to indicate support, just upvote the opening post. If you have something contributory to the feature or use-case (e.g. asking about the probable points in code that needs extending, or suggest new workarounds) then by all means ask. If you have a draft/incomplete code change that you would like a second pair of eyes to review, please open a PR and mark it "work-in-progress".

This is how open-source works. Demanding new features time and again doesn't help at all, and slowly causes mental fatigue / burnout for the small number of developers who are working on it as side projects. In this case the developers are Microsoft, but the situation is the same: they (as a company) have many other issues and money-making projects to spend their limited resources on.

[drorata]

@tanzislam are you still happy with hide-gitignored?

[tanzislam]

Yep, works very transparently as if it were built-in functionality.

[drorata]

After installing hide-gitignored make sure you activate it; run Hide Gitignored: Hide files ignored by .gitignore.

[walles]

hide-gitignored is OK as a workaround until this has been fixed for real, but it's not super.

It basically creates a .vscode/settings.json file that duplicates the .gitignore data in a files.exclude section.

If it could just do its thing without creating new files in my repo that would be preferable.

[drorata]

@walles I would say it is a best practice not to track .vscode anyways, and thus this is, albeit not optimal, a fine solution.

[g-kozulis]

I just wanted to add that I'd very much appreciate this as a built-in feature too.

[mgabeler-lee-6rs]

Requested on Nov 21, 2017

Correction: March 7, 2016: #3764

Exacerbated by the fact that that issue was closed based on the implementation of a feature that did not make any attempt to address the issue as reported.

[mediabeastnz]

A small feature but so important when working. Reduces noise and helps you focus on the task at hand.

Is this likely going to be core or plugin?

[Troy1010]

I want this feature, in either a non-hacky plugin or apart of the core set.
I'm coming from Atom, which has already solved this issue.

[ryancole]

Surprised that core vscode deems the changing of the color of ignored files to be important enough to add as a core feature but not hiding them. Majority of people seem to want hiding to be core feature and not many seem to care about the less useful dimming.

[FernandoMiguel]

Not sure about the majority... I personally prefer dimming, and have no interest in hiding.
And there are many like me

[mrnossiom]

@Milo123459, Did you try to register a new kind of ITreeFilter in the explorerView.ts:

vscode/src/vs/workbench/contrib/files/browser/views/explorerView.ts

Lines 368 to 371 in ca58cb1

	private createTree(container: HTMLElement): void {
	this.filter = this.instantiationService.createInstance(FilesFilter);
	this._register(this.filter);
	this._register(this.filter.onDidChange(() => this.refresh(true)));

This snippet register the FilesFilter class that take care of hiding files.exclude defined files:

vscode/src/vs/workbench/contrib/files/browser/views/explorerViewer.ts

Lines 536 to 540 in ca58cb1

	/**
	* Respectes files.exclude setting in filtering out content from the explorer.
	* Makes sure that visible editors are always shown in the explorer even if they are filtered out by settings.
	*/
	export class FilesFilter implements ITreeFilter<ExplorerItem, FuzzyScore> {

[Milo123459]

Ya, I did try. I gave up though. It's all yours to tackle.

[mrnossiom]

Do you have a rest of some code you wrote ?

[Milo123459]

No, I don't, sorry.

[mrnossiom]

Thanks

[mrnossiom]

So, after just a bit of research, I think there are 2 ways of implementing this:

• Implement a flag that controls vscode-ripgrep in the explorer directly. (Directly built-in)
• Implement a file filter that reads gitignore files and filters them. ITreeFilter (more power cost and space if we used a lib for that)

Obviously, there is a better solution… 👀 (1st one)
Tell me what you think about that.

I continue my researches for the first option.

[Milo123459]

First one is just better..

Less resources used, probably faster and easier to implement. Go with the 1st one.

[mrnossiom]

Research update: just using the vscode-ripgrep flag wouldn't be possible.
A comment before FilesFilter describe the problem.

vscode/src/vs/workbench/contrib/files/browser/views/explorerViewer.ts

Lines 536 to 540 in ca58cb1

	/**
	* Respectes files.exclude setting in filtering out content from the explorer.
	* Makes sure that visible editors are always shown in the explorer even if they are filtered out by settings.
	*/
	export class FilesFilter implements ITreeFilter<ExplorerItem, FuzzyScore> {

We want to be able to show the file in the explorer when actively opened in the editor…

Does some have an idea, or should we go with another option ?

[mrnossiom]

Opinion update: use the vscode-ripgrep flag and let the file hidden in the explorer. Although it is cool to know where is the file you're currently looking at is located, it isn't very useful, and you should know what file you opened through CLI or filename. Also, it is an opt-in flag, so it shouldn't break non-aware users experiences.

Tell me if it could be an option...

[mrnossiom]

Research update: the disregardIgnoreFiles property activate the --no-ignore ripgrep flag we don't want.

vscode/src/vs/workbench/services/search/node/ripgrepFileSearch.ts

Lines 58 to 63 in 419d62a

	if (folderQuery.disregardIgnoreFiles !== false) {
	// Don't use .gitignore or .ignore
	args.push('--no-ignore');
	} else {
	args.push('--no-ignore-parent');
	}

This flag is triggered in many places (just search disregardIgnoreFiles in the repo).

Like there:

vscode/src/vs/workbench/api/browser/mainThreadWorkspace.ts

Lines 146 to 156 in 419d62a

	const query = this._queryBuilder.file(
	includeFolder ? [includeFolder] : workspace.folders,
	{
	maxResults: withNullAsUndefined(maxResults),
	disregardExcludeSettings: (excludePatternOrDisregardExcludes === false) || undefined,
	disregardSearchExcludeSettings: true,
	disregardIgnoreFiles: true,
	includePattern: withNullAsUndefined(includePattern),
	excludePattern: typeof excludePatternOrDisregardExcludes === 'string' ? excludePatternOrDisregardExcludes : undefined,
	_reason: 'startFileSearch'
	});

Or there:

vscode/src/vs/workbench/contrib/searchEditor/browser/searchEditor.ts

Lines 498 to 503 in 419d62a

	const options: ITextQueryBuilderOptions = {
	_reason: 'searchEditor',
	extraFileResources: this.instantiationService.invokeFunction(getOutOfWorkspaceEditorResources),
	maxResults: withNullAsUndefined(this.searchConfig.maxResults),
	disregardIgnoreFiles: !config.useExcludeSettingsAndIgnoreFiles || undefined,
	disregardExcludeSettings: !config.useExcludeSettingsAndIgnoreFiles || undefined,

---

I don't know how to access user configuration yet, but maybe vary the value according to a certain flag.
I think this would be the right place to implement such a thing, but I'm surely wrong…

If an experimented contributor could guide me, I would be really grateful. 👍🏻

[zmaktouf]

Any news on this one ?

[mrnossiom]

Well, as you can see, there is no update since this issue is the feed.
This feature seems complicated to implement properly, and I don't know the codebase enough to make a PR alone.

[mrnossiom]

The new file nesting feature on the new v1.67.0 VS Code make this request less interesting. This new feature kind of replaces this request. I do still something that some people would like to see this added. And the issue is part of the iteration plan of May 2022.
My question is: do we still need this feature, I don't know if this still relevant… ❓

EDIT: 👍🏻 for yes and 👎🏻 for no.

[flisboac]

@mrnossiom How exactly does this new functionality deprecates this issue? For me, they're different things entirely (please do correct me if I'm wrong).

Personally, I still think there's a lot of value in hiding files based on gitignore configuration, as long as it's an opt-in feature. Given the ubiquity of git as a VCS, and the native support VSCode offers for it, it's only natural to have the option to hide those files in your project folder. This is especially desirable for projects usig tools that insist on littering your source folders with temporary/transient files, with no recourse for alternative behaviour (e.g. Python, any TeX-based tool, etc).

[mrnossiom]

@flisboac This was actually my question. I do think that they are different features, but not entirely. Removing temporary files from the explorer view would be useful for a clearer list, but .gitignore files also contains things we do want to see. Also, as far as I've seen, this seems to be quite messy to implement. But maybe the core team will find out, as this is part of the iteration plan.

[flisboac]

@mrnossiom

Removing temporary files from the explorer view would be useful for a clearer list, but .gitignore files also contains things we do want to see.

That's why I think it's important that this is implemented as an opt-in feature. Not every project is the same, so giving this option prevents a lot of work configuring not only your gitignore, but vscode settings as well. In this case, specifically, the developer knows better.

Another idea: a companion setting could also be provided to add specific exceptions, which would be applied only when gitignore is used to hide files. For example:

• files.exclude.gitignore.enabled (bool): activates auto-exclusion of files in gitignores. Respects gitignore files per folder. Default: false.
• files.exclude.gitignore.exceptions (Array<string>): shows any files matching the globs in this list, regardless of whether the file is also a match wrt. some gitignore file. Only applies to gitignore-based file selection. Default: [].

All of that being said... Reading the issue's history again, I see that implementing any part of this feature, in any capacity, will be quite difficult. I also cannot find the time right now to study the codebase or contribute with a PR. But I hope someone can make advances on this; I really think this feature makes sense, and should be provided by vscode itself.

In any case, thank you for your contributions!

[lramos15]

This is now in insiders please feel free to give a test via explorer.excludeGitIgnore. I'll lock this issue to help drive feedback and bugs to new issues as this is just tracking the feature request. Thank you everyone for your patience and I'm excited for us to finally be shipping this feature!