6 ms·
Don't create .gitkeep files, use .gitignore instead (2023)
- yjftsjthsd-h 8mo agoI'm confused. Having a file gitignored doesn't stop you from committing it; AFAIK you can just touch build/.gitkeep git add build/.gitkeep git commit build/.gitkeep And that's it? There's no need to exclude anything.
- williadc 8mo agoThe idea is that you don't want to check-in any builds.
- yjftsjthsd-h 8mo agoSure, so gitignore build/ or whatever. But you don't need to unignore .gitkeep
- akerl_ 8mo agoThe idea is that instead of adding a nonsense file, you use the native .gitignore functionality. ".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.
- dwattttt 8mo agoThis still confuses me. Do you mean to say "use the .gitignore functionality, and check in the .gitkeep file"?
- deleted 8mo ago[deleted]
- akerl_ 8mo agoNo. Use a .gitignore instead of .gitkeep. Instead of checking in build/.gitkeep, check in build/.gitignore.
- dwattttt 8mo agoI don't know that I like this approach. It certainly works, but it's not specifically what (people expect) a .gitignore file to be used for. That confusion isn't good: https://thecodelesscode.com/case/222 https://thecodelesscode.com/case/222 and https://thecodelesscode.com/case/223 https://thecodelesscode.com/case/223
- akerl_ 8mo ago.gitignore is the officially recommended way to do this: https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/GitFaq.html#Can_I_add_empty_directories.3F https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index...
- Supermancho 8mo agoGranted, naming is hard. Routinely using a file named .deleteme or .rememberwalkthedog because it's recommended instead of a more readable solution, is not a compelling reason to switch.
- cortesoft 8mo agoNot sure why you can’t just have your build script create the build directory?
- andybak 8mo agoBecause you might not have a build script?
- drdec 8mo agoThen why do you need a build directory?
- himata4113 8mo agoqemu: mkdir build; cd build; ../configure, some projects are like that
- xigoi 8mo agoWhy can’t the configure script do this?
- hn92726819 8mo agoYou can. But this makes intent clear. If you clone a git repo and see build/ with only a gitkeep, you are safe to bet your life savings on that being the compiled assets dir.
- 1718627440 8mo agoBecause the standard for configure scripts says that the current directory at invocation is the build directory and the location of the configure script is the source directory. You are expected to be able to have multiple build directories if you want them. If you have written your configure script correctly, than in-tree builds (srcdir == builddir) also work, but most people don't want that anyway.
- 8mo ago
- suralind 8mo agoI want to like it, but I pretty much always have a "cleanup" script that just deletes the entire directory and touches a .gitkeep file. Obviously an even better pattern is to not have any .gitkeep files, but sometimes they are just handy.
- macote 8mo agoThe author is misusing .gitkeep. I use it to keep source code folders that don’t contain any code yet, but whose structure is already defined.
- xyzzy_plugh 8mo agoTruly, 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.
- akoboldfrying 8mo ago> Truly, what purpose does this serve? 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.
- xyzzy_plugh 8mo agoLegitimately asking, please share the name of software that expects/requires an empty directory and interprets .gitkeep in this way, but chokes on a README file. 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.
- peter-m80 8mo agoNo, thanks
- Arrowmaster 8mo agoThe 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 agoYeah, 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.
- AgentME 8mo agoIf 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
- 8cvor6j844qw_d6 8mo agoIs .gitkeep an established convention somewhere? I'm curious where the name originated.
- abustamam 8mo agoSeems to originate form this SO post https://stackoverflow.com/a/4250082/28422 https://stackoverflow.com/a/4250082/28422
- jkubicek 8mo agoI'm not sure if I'm the one to blame for this or not, but the earliest reference to ".gitkeep" I can find online is my 2010 answer on Stack Overflow: https://stackoverflow.com/a/4250082/28422 https://stackoverflow.com/a/4250082/28422 If this is all my fault, I'm sorry.
- selridge 8mo agoThis is delightful. Accidental load-bearing SO post.
- pilaf 8mo agoThis 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/785493ffed41abcca0686bf05b0a0157e0844d47 https://github.com/rails/rails/commit/785493ffed41abcca0686b...
- hn92726819 8mo agoYeah... 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.
- deleted 8mo ago[deleted]
- deleted 8mo ago[deleted]
- Kuraj 8mo agoIf you need to do this, I think .gitkeep communicates intent better. You don't need to document it or risk it being removed as thought to be a left over.
- kderbyma 8mo agoArent Gitkeep files specifically for empty folders that are intended to be there? That is what I have always used them for....
- wlonkly 8mo ago.gitkeep has no meaning to Git, only to us meatsacks that recognize the name. As far as Git is concerned, it's just another file.
- OptionOfT 8mo agoFor me, I put them in directories that have to be there, because the underlying code doesn't create the directory, and without it, it fails. 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.
- beej71 8mo agoWhat am I missing about this use case? It seems like you should just create `build/.gitignore` with `*` in it and `add -f` it and be done. 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. :)
- KPGv2 8mo agoThat'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 ```*
- beej71 8mo ago> If you rely on `add -f` you will forget to commit something important. But isn't the idea in TFA to blacklist the entire `build/` tree? We don't want to add anything there.
- KPGv2 8mo agoI have much more than `build` to block. IDE-specific stuff, smalls scripts I write to help me (and go in root) but don't belong in the repo, etc. 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.
- aezart 8mo ago
- GreenDolphinSys 8mo ago.gitkeep is intuitive and easy to understand. Unignoring a .gitignore is not intuitive. This falls squarely into "clever optimization tricks that obscure intent and readability". Don't do things like this. It's not that hard to update a .gitignore file every now and then.
- rswail 8mo agoThen 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.
- trelbutate 8mo agoIf someone doesn't know what .gitkeep is they should be able to derive from the name that it's some special file intended for git. If they then google it they will immediately find out what it's for. Yes, git itself has no concept of it but it's common enough that there's plenty documentation on the internet.
- rswail 8mo agoYes, because relying on google-fu is the way to ensure your build environment is consistent. /s .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.
- throwaway290 8mo ago.gitkeep is not a standard and also because it starts with dot it is hidden by default in file listings which makes it even less intuitive.
- cyberrock 8mo agoFile filtering is so delightfully broken everywhere. Everytime I revisit git, rsync, restic, borg, etc. something just goes wrong somewhere on this seemingly simple task, and SO and thus LLMs are filled to the brim with slightly wrong answers. We need a xkcd/927 because it can't possibly get any worse.
- dmarinus 8mo agoif possible you can also just create directories if they don't exist (ie. mkdir -p) and just exclude it in your root .gitignore (ie. ignore all build directories). That would safe you from creating multiple .gitignore files.
- leecommamichael 8mo agoThis doesn’t solve a problem.
- deafpolygon 8mo agoClaims the wrong thing is common and tells you not to do it , then tells you to do the right thing. 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.
- jiffygist 8mo agoI don't understand why would you ever want to have an empty directory. Besides if I see a directory named "build" I expect to be able to just nuke it any time without consequences.
- prmoustache 8mo agoHow about fixing your build scripts and makefiles instead? Convoluted solutions for a non-existing problem.
- zahlman 8mo agoOh, man, I'd forgotten about these negated .gitignore patterns entirely. It actually hadn't occurred to me that they could override the behaviour of ignoring empty directories. 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. :(
- ivan_gammel 8mo agoWhy not having a txt file with indented tree, a bootstrap function that parses the file and creates the tree and a test for that function? You will have proper diff for the tree this way.
- zahlman 8mo agoWell, partly because I already have a tool similar to that in mind as a separate project :) (The files also need to have certain content, so I need something a bit more complex that can specify that.) But mainly because, as you acknowledge, that process needs its own tests. Basic unzipping functionality is already tested for me.
- hollasch 8mo agoMy preference is to use the build system to create built artifacts, and I consider the build/ directory to be a built artifact. Wrangling Git into doing the first fundamental build step is off, in my opinion. 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.
- taftster 8mo agoBoth points here are appreciated. One that a README file as a "placeholder" for a directory gives the opportunity to describe why said empty directory exists. I would be slightly concerned though if my build process picked up this file during packaging. But that's probably a minor concern and your point stands. 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.
- globular-toast 8mo agoI find this use of .gitignore far more common than .gitkeep. I did see one js tool creating them and did wonder what it was about.
- Joker_vD 8mo agoWhy did Git decide to have no means to track fully empty directories? Like, I understand that e.g. doing "git rm *" inside a directory should probably delete this directory from the repository as well (although "git rm -r dir_to_delete" exists so...) but why not have a command to explicitly force a directory to be tracked, whether it's empty or not?
- huflungdung 8mo ago[dead]
- lofaszvanitt 8mo agoWhy didn't anyone implement it? And an option to keep attrs, rights, owners, groups etc.
- JuniperMesos 8mo agoMaybe the correct thing to do is to modify git so that it can track an otherwise-empty directory and then never have to worry about this problem again. Is there a reason why this is hard to integrate into git's existing model of the filesystem?
- lucketone 8mo ago1. Nobody sees this as a big issue. 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)
- 1718627440 8mo agoGit only tracks files not directories, so yeah you would need to change a lot. It is also unclear what the semantics should be. What is with a directory that is tracked as r--, but then files get added?
- phelm 8mo agocould you just add "!.gitkeep" to .gitignore?
- darepublic 8mo agoIn some cases gitkeep can make sense. Just let people choose the right tool