[Arrowmaster]

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 to it will be tracked without needing to use --force with git add.

[BlackFly]

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.

[ekipan]

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 a good tradeoff there.

[Aaron2222]

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

[_kst_]

If you want any kind of non-trivial formatting, use the printf command, not echo.

[AgentME]

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.

[xg15]

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.

[1718627440]

But ignore files are only for untracked files anyway. Maybe you want them to specify what can be in the repo and what not, but this is not how Git works.

[nebezb]

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.

[smrq]

Why is this approach better than the author's?