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.
The point of that line is to robustly survive a rename of the directory which won't be automatically tracked without that line. You have to read between the lines to see this: they complain about this problem with .gitkeep files.
Yeah, this. Plus a mistake from the article:
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 a good tradeoff there.
> The \n won't be interpreted specially by echo unless it gets the -e option.
Author's probably using Zsh, which interprets them by default.
If you have a project template or a tool that otherwise sets up a project but leaves it in the user's hands to create a git repo for it or commit the project into an existing repo, then it would be better for it to create a self-excepting .gitignore file than to have to instruct the user on special git commands to use later.
I think I'd prefer to have all ignores and un-ignores explicitly in the file and not have some of them defined implicitly because a file was added to tracking at some point.
This is functionally the same. What do you mean by “you should never”? According to who?
What an arrogant take. This is preference. Don’t mistake it for correctness.
Why is this approach better than the author's?