41–50 of 101 posts
The author makes a very common mistake of not reading the very first line of the documentation for .gitignore. A gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected; see the NOTES below for details. You should never be putting "!.gitignore" in .gitignore. Just do `echo "*" > .gitignore; git add -f .gitignore`. Once a file is tracked any changes…
What an arrogant take. This is preference. Don’t mistake it for correctness.
The author makes a very common mistake of not reading the very first line of the documentation for .gitignore. A gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected; see the NOTES below for details. You should never be putting "!.gitignore" in .gitignore. Just do `echo "*" > .gitignore; git add -f .gitignore`. Once a file is tracked any changes…
Yeah, this. Plus a mistake from the article: $ echo '*\n!.gitignore' > build/.gitignore The \n won't be interpreted specially by echo unless it gets the -e option. Personally if I need a build directory I just have it mkdir itself in my Makefile and rm -rf it in `make clean`. With the article's scheme this would cause `git status` noise that a `/build/` line in a root .gitignore wouldn't. I'm not really sure there's…
Author's probably using Zsh, which interprets them by default.
The author makes a very common mistake of not reading the very first line of the documentation for .gitignore. A gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected; see the NOTES below for details. You should never be putting "!.gitignore" in .gitignore. Just do `echo "*" > .gitignore; git add -f .gitignore`. Once a file is tracked any changes…
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 `.gitkee…
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/*.j…
But isn't the idea in TFA to blacklist the entire `build/` tree? We don't want to add anything there.
I'm not sure if I'm the one to blame for this or not, but the earliest reference to ".gitkeep" I can find online is my 2010 answer on Stack Overflow: https://stackoverflow.com/a/4250082/28422 If this is all my fault, I'm sorry.
https://github.com/rails/rails/commit/785493ffed41abcca0686b...
I have never heard of .gitkeep before today, and if you need an empty directory to exist, use a build script.
Don’t do stupid workarounds.