Ignore gitignore rules when explicitly searching inside an ignored dir

[nyurik]

To improve usability, I think it would be good to ignore the rules in .gitignore when the user tries to search inside a dir that is already ignored. This will result in far fewer "gotcha" moments. For example, assume I am searching inside a Rust project:

fd rmeta
# no results because all *.rmeta files are in the target/ dir, which is in .gitignore
fd rmeta target/
# No results because .gitignore has a `*.rmeta` rule too. Instead, I think it
# should show lots of results because I am searching explicitly inside an ignored dir

Note that .gitignore may have multiple rules, e.g. target/ and *.rmeta, but I believe the logic for ignoring should be: "if the dir is excluded, but gets included because fd is ran inside of the ignored dir or is explicitly listed as a param, automatically enable the -I param`

[tavianator]

I believe the logic for ignoring should be: "if the dir is excluded, but gets included because fd is ran inside of the ignored dir or is explicitly listed as a param, automatically enable the -I param

I think that's a little too aggressive: what if there is another git directory within the search path? I think its .gitignore should still be respected. The right behaviour might be to enable --no-ignore-parent instead, if the search path itself is ignored.

[nyurik]

@tavianator not certain I understood what you mean. In case of a nested git repo, fd should respect the "closest" .gitignore up the tree.

[tavianator]

Right, but if you turn on -I, fd won't respect any .gitignores at all

[tavianator]

Oh but actually, I think I misinterpreted your question a bit. fd pattern ignored-dir already kind of does what I was suggesting. I thought it would give no results at all since the search path was ignored, but it indeed does give some results. Your point is that it still respects other .gitignore rules from the parent, which might not be helpful if we're already inside an ignored directory.

[tavianator]

However, I still think --no-ignore-parent is what you want, not -I. You can try fd rmeta target/ --no-ignore-parent yourself and see that it does the right thing. The difference is apparent if you clone another git repo inside target/.

[nyurik]

@tavianator correct, that's the issue i was running into, and was very confused, esp after I already used the -H, and didn't realize it was due to the missing -I. You are right that the --no-ignore-parent would have worked, but we are talking about usability -- I was not even aware of that flag until you mentioned it -- I think the tool should work in the most non-surprising way possible by default, to minimize the confusion of the new users. Do you think the --no-ignore-parent should be enabled by default?

[tavianator]

Do you think the --no-ignore-parent should be enabled by default?

No, I just think that

if the dir is excluded, but gets included because fd is ran inside of the ignored dir or is explicitly listed as a param, automatically enable the -I param

is not the right fix, but

if the dir is excluded, but gets included because fd is ran inside of the ignored dir or is explicitly listed as a param, automatically enable the --no-ignore-parent param

is the right fix.

[nyurik]

ah, sure, that could also work, thanks! You basically propose a new --ignore-parent=auto mode, right?