Hacker News

Yeah... I don't think you were wrong. Having 100 tiny gitignores makes finding out why something is excluded annoying. Our policy is one root level gitgnore and gitkeeps where required.

Some devs will just open the first gitignore they see and throw stuff into it. No thank you.

This Rails commit from May 2010 mentions gitkeeps and it's a few months older than your SO post, so it seems you're absolved from guilt:

https://github.com/rails/rails/commit/785493ffed41abcca0686b...

This is delightful. Accidental load-bearing SO post.

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.

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.

Yeah, this. Plus a mistake from the article:

  $ echo '*\n!.gitignore' > build/.gitignore

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.

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.

Why is this approach better than the author's?

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.

Then put a comment in the .gitignore.

Using the actual tools built in to git directly removes steps in the process, which is always a good thing, it's documented as part of the git documentation, so you don't have to create a wiki page explaining why there is a ".gitkeep" file that git doesn't recognize itself.

Saying "It's not that hard..." is fine for projects with a few contributors but does not scale.

Usually, you can. But occasionally you get mildly defective tools that require some directory to exist, even though it's empty. It's easier to add a gitkeep than fix them.

There may be other directories. I think it's useful to be able to see the entire directory structure of a repo when you check it out, and not just after running some scripts.

Because you might not have a build script?

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.

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

```*

Seems to originate form this SO post

https://stackoverflow.com/a/4250082/28422

The idea is that you don't want to check-in any builds.

Truly, what purpose does this serve? Defining a hierarchy without using is injecting immediate debt. Just introduce it when stuff goes there! If you really insist then at least put something in the folder. It doesn't take much effort to make the change at least a tiny bit meaningful.

Better yet just do the work. If you want make a commit in a branch that's destined to be squashed or something, sure, but keep it away from the shared history and certainly remove it when it's not needed anymore.

You can rename `.gitkeep` to `.gitignore` and both be happy in that case.