What am I missing about this use case? It seems like you should just create `build/.gitignore` with `*` in it and `add -f` it and be done.
I'd use `.gitkeep` (or an empty `.gitignore`) if I needed to commit an otherwise-empty hierarchy. But if I'm going to have a `.gitignore` in there anyway, it's not empty.
> The directory is now “tracked” with a single, standard file that will work even after renames.
Does `.gitkeep` not work after renames? Or `.gitignore`?
So I am missing something. :)
It makes the behavior more obvious from simply looking at the file, for one thing, and it means you can just lump it into your next `git add -A` without needing to handle it specially.
That's a hack. What you should do is a .gitignore with * and then a whitelist of paths like src/**/*.
If you rely on `add -f` you will forget to commit something important.
For example, for a tree sitter grammar I developed a couple years ago, here is my .gitignore:
```
# Ignore everything
*
# Top-level whitelist
CHANGELOG.md
# Allow git to see inside subdirectories
!*/
# Whitelist the grammar and tests
!/grammar/*.js
!/test/corpus/*.txt
# Whitelist any grammar and tests in subdirectories
!/grammar/**/*.js
!/test/corpus/**/*.txt
```*
> If you rely on `add -f` you will forget to commit something important.
But isn't the idea in TFA to blacklist the entire `build/` tree? We don't want to add anything there.
I have much more than `build` to block. IDE-specific stuff, smalls scripts I write to help me (and go in root) but don't belong in the repo, etc.
And what if for some reason you accidentally copied a big Linux ISO to that directory by mistake. Without a whitelist, you might accidentally add and commit a 700MB file to your main and not even notice. What a pain when you push later and have to git amend, rebase -i, etc.
Better to block all except whitelist. The only downside is it's less obvious how to do this than allowing all except blacklist to new git users.