4 ms·

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` (

by beej71 8mo ago

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. :)

KPGv2 8mo ago
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 ```*
- beej71 8mo ago
  > 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.
  - KPGv2 8mo ago
    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.
aezart 8mo ago
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.

by beej71 8mo ago

KPGv2 8mo ago

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 ```*

beej71 8mo ago
> 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.
- KPGv2 8mo ago
  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.

aezart 8mo ago

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.