3 ms·

The author makes a very common mistake of not reading the very first line of the documentation for .gitignore. A gitignore file specifies intentionally untra

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.

ekipan 8mo ago
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 8mo ago
  > 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_ 8mo ago
    If you want any kind of non-trivial formatting, use the printf command, not echo.
AgentME 8mo ago
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.
smrq 8mo ago
Why is this approach better than the author's?
nebezb 8mo ago
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.
BlackFly 8mo ago
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.
xg15 8mo ago
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 8mo ago
  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.

ekipan 8mo ago

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 8mo ago
> 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_ 8mo ago
  If you want any kind of non-trivial formatting, use the printf command, not echo.

AgentME 8mo ago

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.

smrq 8mo ago

Why is this approach better than the author's?

nebezb 8mo ago

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.

BlackFly 8mo ago

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.

xg15 8mo ago

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