If this is all my fault, I'm sorry.
https://github.com/rails/rails/commit/785493ffed41abcca0686b...
The Peter Cederqvist manual recommended the practice.
Here is a 1993 dated copy someone left hosted:
https://www.astro.princeton.edu/~rhl/cvs/cvs.html
The paragraph which recommends the .keepme files is:
https://www.astro.princeton.edu/~rhl/cvs/cvs.html#SEC63
"if you want an empty directory then put a dummy file (for example `.keepme') in it to prevent `-P' from removing it."
Some devs will just open the first gitignore they see and throw stuff into it. No thank you.
This is not a complicated or important enough problem to justify a team-wide policy. Let it work itself out naturally.
https://git-scm.com/docs/git-check-ignore makes it trivial to debug repo-wide gitignore behavior.
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.
$ 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.
Author's probably using Zsh, which interprets them by default.
What an arrogant take. This is preference. Don’t mistake it for correctness.
However, if you disagree, my favorite "Git keep" filename is "README.md". Why is this otherwise empty directory here, how does it fit into my source tree, how is it populated, and so forth.
One of my pet peeves with the latest AI wave is the time we spend creating files to help AI coding agents, but don't give the same consideration to the humans who have to maintain and update our code.
Additionally, the AI comment is ironic as well. It's like we're finally writing good documentation for the sake of agents, in a way that we should have been writing all along for other sentient consumers. It's funny to see documentation now as basically the horse instead of the cart.
It's not that hard to update a .gitignore file every now and then.
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.
Your point is valid though. It would be much preferable to include build/ in your root .gitignore so that the directory is never tracked.
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 `.gitkeep` not work after renames? Or `.gitignore`?
So I am missing something. :)
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
```*
But isn't the idea in TFA to blacklist the entire `build/` tree? We don't want to add anything there.
That is what I have always used them for....
This is potentially actually useful for me, because I have a project with test data that consists of miniature filesystem sub-trees — that should include empty directories to ensure edge cases are covered. I've been zipping them up and having the test harness unpack them in the test environment, but that's an unnecessary extra point of failure (and it stuffs undiffable binary files into the commit history).
Edit: Ah, no, if this doesn't work from the project-global .gitignore (specifying a folder to keep, even though it's empty and doesn't even have its own .gitignore) then it doesn't solve the problem. :(
You will have proper diff for the tree this way.
But mainly because, as you acknowledge, that process needs its own tests. Basic unzipping functionality is already tested for me.
Another example is where you want an empty directory mounted in Docker. If the directory is not there it is created with root permissions and then I can't even look into it.
2. As-is situation is good enough.
3. I guarantee that you will have colleagues that will accidentally add empty dirs. (I definitely have seen when they accidentally add built artefacts; dirs would be lesser issue as they would not increase repo size by much, but still)
4. Actually only first two reasons matter, but for nitpickers there would be also a bit dishonest but formally correct pointing to some doc saying that it is file or content tracker (and formally directory is not a content)
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.
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.
To manually install it, you must clone the repo. Then you have to download models into the right place. Where's the right place? Well, there's an empty directory called models. They go in there.
IMO that's an effective use of gitkeep.
The simplest answer is that sometimes other existing software that I need to use treats an empty directory (or, hopefully, a directory containing just an irrelevant file like .gitkeep) differently from an absent directory, and I want that software to behave in the first way instead of the second.
A more thorough answer would be: Filesystems can represent empty directories, so a technology that supports versioned filesystems should be able to as well. And if that technology can't quite support fully versioned filesystems -- perhaps because it was never designed with that goal in mind -- but can nevertheless support them well enough to cover a huge number of use cases that people actually have, then massaging it a bit to handle those rough edges still makes sense.
touch build/.gitkeep
git add build/.gitkeep
git commit build/.gitkeep
I heard facebook allows any language as long as you have packaged it neatly with all required build chain. (I.e. Even a choice of language works out)
Some lowest common denominator will be reached. (1 :) )
On the other hand: Are we happy with the lowest or do we want to aim higher?
.gitkeep is explicitly not intended for git, because git doesn't recognize it at all.
Having the .gitignore, which is actually recognized by the git tools, means you can rely on the .gitignore functionality, including ensuring that things other than the .gitignore cannot be added to the repo.
And what if for some reason you accidentally copied a big Linux ISO to that directory by mistake. Without a whitelist, you might accidentally add and commit a 700MB file to your main and not even notice. What a pain when you push later and have to git amend, rebase -i, etc.
Better to block all except whitelist. The only downside is it's less obvious how to do this than allowing all except blacklist to new git users.
echo >repo/models/README.md "this is the directory you place models in"
https://github.com/Comfy-Org/ComfyUI/blob/master/models/diff...
But in any case, that instruction was already in the readme as well.
echo >repo/models/README.md "this is the directory in which you place models"
Pedant
Many filesystems cannot represent empty directories. Many archive formats also do not. I don't think this a problem in practice. I find this argument extremely weak.
Every mail server since postfix supports Maildir, in which every email is a file in one of 3 subdirectories (tmp, new or cur) of a user directory. If there's no jbloggs/tmp dir, postfix will think user jbloggs does not exist. So if you want to take a restorable snapshot of this with git, there needs to be a file there. I don't know if jbloggs/tmp/README would cause a problem, because I don't know how postfix will treat the presence of a file with a name that violates its expected syntax (which includes a timestamp and other metadata), but what I do know is that, after running `git clone any-repo`, I can safely delete every .gitkeep file to restore the system to its original state without having to understand that repo in detail -- while I cannot safely delete every README file. That's because the commonly understood semantics of .gitkeep is "I exist solely to shoehorn this empty dir into git", which does not apply to other files.
> Many filesystems cannot represent empty directories
Your turn -- name one.
Like which ones? And how does mkdir(1) work on such filesystems?
".gitkeep" is just a human thing; it would work the same if you called it ".blahblah".
So their pitch is that if you want to explicitly keep the existence of the directory as a committed part of the repo, you're better off using the actual .gitignore functionality to check in the .gitignore file but ignore anything else in the directory.
I don't find it amazingly compelling; .gitkeep isn't breaking anything.