Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Entering a full path in quickopen matches gitignored files, but not search.excluded files #41495

Closed
scottsb opened this issue Jan 12, 2018 · 7 comments
Assignees
Labels
*as-designed Described behavior is as designed search Search widget and operation issues

Comments

@scottsb
Copy link

scottsb commented Jan 12, 2018

  • VSCode Version: Code 1.19.2 (490ef76, 2018-01-10T15:49:04.682Z)
  • OS Version: Darwin x64 17.3.0
  • Extensions: none

It's hard to identify the exact circumstances that trigger this, but starting from some recent version (either 1.18 or 1.19), quick open began consistently missing files that it should clearly match. This seems to happen most particularly in large repositories with many files.

To illustrate here is a screen recording of an obvious case:

missingfiles

@vscodebot vscodebot bot added the workbench label Jan 12, 2018
@bpasero bpasero added search Search widget and operation issues and removed workbench labels Jan 12, 2018
@bpasero bpasero assigned roblourens and unassigned bpasero Jan 12, 2018
@bpasero
Copy link
Member

bpasero commented Jan 12, 2018

Since I see the label "file results", this seems to be an issue with the RipGrep matching and not with the fuzzy scorer of quick open that is only used for sorting purpose as far as I know.

@roblourens
Copy link
Member

Are those files covered by a gitignore pattern? It now skips gitignored files by default. You can disable this with "search.useIgnoreFiles": false if you prefer.

If that's not it, do you see any pattern to which files it can't find (besides "recently opened" files, which are searched differently)

@roblourens roblourens added the info-needed Issue requires more information from poster label Jan 12, 2018
@scottsb
Copy link
Author

scottsb commented Jan 12, 2018

It does appears the issue was related to .gitignore. These were in the Composer-managed vendor directory, which we don't track. Is that new setting ignored when you enter the full path? You can see in my GIF that it came up when I entered that, but not when I entered a partial path.

@roblourens
Copy link
Member

roblourens commented Jan 12, 2018

I do see that - when you enter a full path like that, it matches immediately and bypasses the actual search that's looking at the gitignore file. But this is inconsistent with search.exclude - if it's excluded that way, it still won't match if you enter a full path. That seems wrong... I'll use this bug to track that.

@roblourens roblourens added bug Issue identified by VS Code Team member as probable bug and removed info-needed Issue requires more information from poster labels Jan 12, 2018
@roblourens roblourens changed the title Quick open fuzzy matching misses files Entering a full path in quickopen matches gitignored files, but not search.excluded files Jan 12, 2018
@chrmarti
Copy link
Contributor

Absolute paths and paths from a root folder should always match, ignoring the search.exclude and .gitignore settings. At least that is how we designed it.

@roblourens
Copy link
Member

Ok. Seems like that doesn't work for .exclude settings anymore, I guess that's the bug.

@roblourens
Copy link
Member

This should now work consistently for absolute paths but not relative paths, by design.

@roblourens roblourens added *as-designed Described behavior is as designed and removed bug Issue identified by VS Code Team member as probable bug labels Sep 12, 2018
@vscodebot vscodebot bot locked and limited conversation to collaborators Oct 27, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
*as-designed Described behavior is as designed search Search widget and operation issues
Projects
None yet
Development

No branches or pull requests

4 participants