Live data from Hacker News

Don't create .gitkeep files, use .gitignore instead (2023)

adamj.eu

71–80 of 101 posts

Re: Don't create .gitkeep files, use .gitignore instead (2023)

#71

I'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 If this is all my fault, I'm sorry.

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.

I agree with you. Empty .gitignore would be a "smell" to me. Whereas .gitkeep tells me exactly what purpose it serves. I like the semantic difference here that you describe. I don't like when multiple .gitignore files are littered throughout the codebase.

Re: Don't create .gitkeep files, use .gitignore instead (2023)

#73

My 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…

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

Re: Don't create .gitkeep files, use .gitignore instead (2023)

#74
Why 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?

Re: Don't create .gitkeep files, use .gitignore instead (2023)

#75
post #63

Not sure why you can’t just have your build script create the build directory?

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.

This used to happen a lot. But I don't think that many modern builders require existing directory these days.

Your point is valid though. It would be much preferable to include build/ in your root .gitignore so that the directory is never tracked.

Re: Don't create .gitkeep files, use .gitignore instead (2023)

#76

Earlier quoted context omitted.

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

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

> Many filesystems cannot represent empty directories.

Like which ones? And how does mkdir(1) work on such filesystems?

Re: Don't create .gitkeep files, use .gitignore instead (2023)

#77

Why 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?

[dead]

Re: Don't create .gitkeep files, use .gitignore instead (2023)

#78
post #65

Oh, 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…

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

Re: Don't create .gitkeep files, use .gitignore instead (2023)

#79

Why 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?

Why didn't anyone implement it? And an option to keep attrs, rights, owners, groups etc.

Re: Don't create .gitkeep files, use .gitignore instead (2023)

#80

Arent Gitkeep files specifically for empty folders that are intended to be there? That is what I have always used them for....

.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.
Post reply on HN