Fd: Ignoring files added with 'git add --force'

[christianbundy]

Describe the bug you encountered:

It seems that fd is respecting .gitignore rather than respecting Git.

$ git init
$ echo foo > .gitignore
$ touch foo
$ git add --force .gitignore foo
$ git ls-files
.gitignore
foo
$ fd --hidden --type f --maxdepth 1
.gitignore

This is a problem for me because I have a .gitignore with the value *, and I'm manually adding all files with git add --force.

Describe what you expected to happen:

Git integration should have the same behavior as Git.

$ git fd --hidden --type f --maxdepth 1
.gitignore
foo

What version of fd are you using?

8.1.1

Which operating system / distribution are you on?

Darwin 19.6.0 x86_64

---

See-also: https://github.com/sharkdp/fd/issues/612

[tmccombs]

It seems that fd is respecting .gitignore rather than respecting Git.

Yes, that is how the ignore crate that fd uses, and thus fd, works. It may be better to file this issue against https://github.com/BurntSushi/ripgrep/tree/master/crates/ignore.

However, I'm not sure if it is feasible to use git ls-files or equivalent without hurting performance.

[sharkdp]

A personal note:

Having files being explicitly ignored via .gitignore but then choosing to add them to the index via git add is an "anti pattern", in my point of view. It causes problems with all sorts of tools (including git itself) and I have personally banned this pattern from my open source projects and at work. I'm not saying anyone has to follow my suggestions, but it's definitely not clear to me what this even means, semantically: you want a file to be tracked by Git, but you choose to git-ignore it at the same time.

When I say "including git itself", I'm talking about the following problem:

1. developer A thinks it would be a good idea to ban all kinds of binary content from a repository and adds a *.png pattern to the .gitignore.
2. developer B thinks that it would actually be a good idea to track the documentation for the project inside the repository itself, including an image of the architecture: doc/architecture.png. Instead of explicitly allowing PNG files in the doc folder (or everywhere), the image is simply added via git add. Everything seems to work just fine.
3. developer C works on the documentation and (in the process) creates a new doc/architecture-detail.png image. C continues to work for a while, modifies some other files, and eventually decides to commit. C calls git status to see a list of changed files. Since the new PNG file is .gitignored and not listed in git status, C forgets to git add it and only pushes the other updates. Cs workspace now seems completely clean (git status does not show anything), so C decides to switch back to the master branch and calls git clean (or similar) to have a fresh repository state without all of the binary "build artifacts". Cs architecture-detail.png file is now lost forever.

This might sound hypothetical, but I have personally experienced this problem a few times too often.

The problem is in step 1 (and partially in step 2): What is the reason for adding a *.png pattern? The main argument from developer A that I have seen is that they don't want other developers to accidentally commit large files to the repository. My response would be to teach other developers to not use git add ., but rather add files selectively. If you don't trust others, maybe add a pre-commit hook that rejects large binary files. But don't add overly generic patterns to the .gitignore file.

[christianbundy]

Thanks, that makes a lot of sense. For what it's worth, my use-case is managing my dotfiles, and I'm using this technique to maintain an allow-list. My problem with .gitignore is when you want to:

• Ignore by default.
• Selectively add nested directories (e.g. x/y/z).

For this, you need a .gitignore with the contents:

/*
!/x
/x/*
!/x/y
/x/y/*
!/x/y/z

(This prevents Git from seeing /a, /x/b, or /x/y/c.)

This is un-ergonomic enough that I've started maintaining an allow-list in .gitallow, which is used to generate a .gitignore that provides the above patterns.

Links:

• .gitignore
• .gitallow
• git-allow (script)

Anyway, I suppose that I want to point out that I agree with you, and that I've also come to prefer a .gitignore over git add --force. I'm also sympathetic to performance concerns, and it's alright with me is fd avoids full Git integration for to keep performance high.