Fd: Disable .gitignore and .fdignore by default

[ChengCat]

These ignoring rules are useful when you know about them, but could be surprising if fd is used as a simple tool to replace find, especially for a new user.

BTW, I agree with removing .ignore and .rgignore, and adding .fdignore.

[sharkdp]

:-1: from me. I agree that it might be surprising if you don't know about it, but fd is not trying to be 100% compatible with find. I still believe that respecting .gitignore is the right default, even if I sometimes use -I/--no-ignore. In particular, I love to use a plain fd in the root of a git repository to get an overview of all files.

Also, I think it's easy enough for everyone to choose their own defaults (alias fd="fd -I").

[ChengCat]

I believe we should make the general use case (i.e. searching general files) as the default. It is easy enough to add an option for source code searches.
I am expecting this to be a system utility, the above reasoning does not hold if you intend this to be a development tool.

[tmccombs]

My impression is that the purpose of fd is primarily as a more user-friendly version of find for interactive use, not a drop in replacement for find in all cases (correct me if I'm wrong @sharkdp).

fd is to find as ripgrep (or ag) is to grep. And by default ripgrep respects .gitignore, .ignore, and .rgignore.

[sharkdp]

@ChengCat

I believe we should make the general use case (i.e. searching general files) as the default.

Regarding the "general user":

• If the user is not a developer, I don't expect there to be any Git repositories with ignore files in the search path, so there shouldn't be any confusion.
• If the user is a developer and has Git repositories in the search path, I expect the ignore-by-default option to be the right choice in almost all cases. Agreed, there are cases where you want --no-ignore for a particular search, but this is a thing that users will have to learn when they want to use fd. We could certainly think about improving the documentation (--help text, man page) in this respect.

@tmccombs

My impression is that the purpose of fd is primarily as a more user-friendly version of find for interactive use, not a drop in replacement for find in all cases

Yes, absolutely.

@ChengCat

I am expecting this to be a system utility

I don't see any reason why fd can not be used as a system utility. It's just not a drop-in replacement for find, and never intended to be. But you can always go back to find-like behavior with fd -HI or fd -uu.

[ChengCat]

@sharkdp

Please note that I said "general use case" rather than "general user". By general use case, I mean searching any files in the file system, whether it's code or not. The current default behavior is biased towards searching only source code files, and this makes fd more a software development utility than a general utility.

I understand that fd will probably never be a drop-in replacement for find. But as a system utility, it is still confusing to be biased towards source code searching. A system utility is assumed to be for general use, and have no idea whether a file is code, at least in the default mode.

• If the user is not a developer, I don't expect there to be any Git repositories with ignore files in the search path, so there shouldn't be any confusion.
• If the user is a developer and has Git repositories in the search path, I expect the ignore-by-default option to be the right choice in almost all cases. Agreed, there are cases where you want --no-ignore for a particular search, but this is a thing that users will have to learn when they want to use fd. We could certainly think about improving the documentation (--help text, man page) in this respect.

The chance that fd get misused because of this issue is unclear to me. It could be used in scripts if it gets wide adoption. One thing I'm sure is that misusing happens (#170), and when this happens it could be disastrous. I don't think this is acceptable as a system utility, and this is what concerns me. I think you should either make it clear that this is not a system utility, or change this default behavior.

@tmccombs

ripgrep is also bad from a system utility perspective, but the author makes it clear that it's intended as a code searching tool. (https://github.com/BurntSushi/ripgrep/issues/689#issuecomment-347173094)

[sharkdp]

But as a system utility, it is still confusing to be biased towards source code searching.

No. fd simply tries to provide defaults that are useful for the general use case. It makes certain assumptions. One assumption is that hidden files (starting with a leading dot) are hidden for a good reason. This is why they are not displayed by default. Another assumption is that files that someone entered into a ignore-file are generally not interesting as search results either. This is why they are also hidden by default.

In any case, I don't understand why you think that it's not suited as a "system utility". As with any other tool, the user has to understand what the tool is supposed to do. If you want to use fd to search for each any every possible file, you need to use the unrestricted mode which can be enabled by -HI or -uu.

[ChengCat]

No. (...) Another assumption is that files that someone entered into a ignore-file are generally not interesting as search results either.

I don't get why this is a no. You acknowledge that you made certain assumptions, and I am saying your assumptions are problematic.

The assumption that the files specified in .gitignore are not interesting, is probably only most valid when the user is a developer. .fdignore is also problematic, because, unlike hidden files, .fdignore isn't a widely accepted mechanism.

In any case, I don't understand why you think that it's not suited as a "system utility".

From my perspective, it is pretty obvious. Maybe my arguments are not well-written, but I don't understand why you still don't get the point. A system utility definitely must not do anything "magic" behind my back, and should be dumb and transparent. Trading reliability for convenience is irresponsible IMO, especially for a system utility.

As with any other tool, the user has to understand what the tool is supposed to do.

We are talking about software design, and this argument is irrelevant. Even the worst-designed thing can be properly used by carefully reading documentation.

If you want to use fd to search for each any every possible file, you need to use the unrestricted mode which can be enabled by -HI or -uu.

This is fine and preferable if it's a development tool.

---

FYI, I recently found that https://github.com/ogham/exa does not do this by default, which is in a similar spirit, i.e. traditional tool replacement written in Rust.

I won't comment on this issue further. I have spent too much time and energy on this, and I have removed fd from my system, so contributing comments won't benefit myself. Sorry, but this meant no offense. Traditional established tools are better for me, and I learned that they are still in use for a reason.

[sharkdp]

What about the hidden files? Do you think that's a bad choice as well? In my point of view, it's the same kind of argumentation.

[crabvk]

@sharkdp

Another assumption is that files that someone entered into a ignore-file are generally not interesting as search results either.

.gitignore is for files and folders you don't want to track changes of. Some of them are tmp, build, compressed or compiled binary files, but the others are logs or vendor source files, such as in node_modules, deps (elixir mix), etc.
You could say "just use fd 'query' node_modules", but then you're missing the point.

So, a user developer should know and recall the contents of .gitignore (and all nested ones) every time use fd? Is this what you call "user-friendly"?

User better make assumption that .gitignore will hide his search results and always use fd -I or an alias.

I don't see any reason why fd can not be used as a system utility.

It can, just like git can be used to make and apply patches (functionality of diff and patch system tools). But fd's default behaviour depends on development config .gitignore, which is by devs and for devs. fd expects you to know about .gitignore by default, hence it is a development tool. So, it's not "user-friendly", it is "developer-friendly".

If the user is not a developer, I don't expect there to be any Git repositories with ignore files in the search path, so there shouldn't be any confusion.

Your expectation (one more assumption) easily can be wrong. And if a regular user faced .gitignore file in his search dir, should he become a developer? Or lets just warn all the users "Always use fd -I if you're not a developer".

@ChengCat, you are totally right.

[sharkdp]

So, a ~user~ developer should know and recall the contents of .gitignore (and all nested ones) every time use fd?

No, but you will have to remember that fd ignores .gitignore entries, by default. That is a conscious design choice that we made.

but the others are logs or vendor source files, such as in node_modules, deps (elixir mix), etc.

Yes, there are valid use cases where you want to find these files. You will have to remember to use -I in these cases.

Our assumption with fd is that >90% of the time, if you are using fd in a Git repository, you don't want to see search results that were explicitly flagged as "ignored". node_modules is a perfect example of a folder that I typically don't want to search. If I do, I need to remember to use -I. And yes, it can be surprising and it might be bothersome to add -I in these cases.