On some folder, Cmd+T always tells me "Project is empty"

[vincentisambart]

As you can see on the screenshot below:

Atom was started with atom --safe <directoryname>.
OS X 10.10.3, Atom 1.0.
Other folders work well.
(moved from atom/atom#7520)

[vincentisambart]

It's probably because that directory is in the .gitignore of its parent directory.
Reproduction:

git clone --depth 1 https://github.com/CocoaPods/Rainforest.git
cd Rainforest
rake bootstrap # you can Ctrl+C as soon as the CocoaPods directory has been cloned
atom --safe CocoaPods

Then if you press Cmd+T you will get the screenshot above.

[michaelaye]

Have the same problem and yes, I have another git repo above this project that ignores all folders to keep track of some general setting files that are applicable for all projects underneath. So my .gitignore has the line */. Is there a workaround to still be able to use the fuzzy finder?

[spencern]

Same issue here.
Happening for directories that are .gitignored in parent for me as well.

[maaarghk]

This is happening here also; I would expect the .gitignore which is up a few levels not to be read as the project itself has its own .git folder; is there a more appropriate place to raise this bug to do with the way ignoredNames are dealt with, or is this with the fuzzy-finder project?

[maaarghk]

^ further to this, it seems fuzzy finder is the only thing which is affected, everything else manages alright. So I think this is the correct place for this bug.

[aaronjensen]

From what I can tell, the issue only seems to be with */ being ignored. If you simply ignore CocoaPods it works as expected.

[maaarghk]

^ can confirm.

I have the following structure

/project
|
|-- things
|--|-- thing1
|--|-- thing2
|--|-- .gitignore
|
|-- .gitignore

If I put "things" in /project/.gitignore then fuzzy finder works as expected with thing1/thing2 folders as project base directories.

If I however put in /project/things/.gitignore :

*
!.gitignore

because I want the folder to remain empty in source control, then the fuzzy finder does not work correctly in the same situation.

[kemayo]

Okay, #152 now includes a spec for this issue. So, regardless of whether my approach is settled on, if someone else wants a starting point for looking at it...