Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

adamj.eu

Post reply on HN
Print view View original

81–90 of 101 posts

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

#81

Post by zahlman »

ivan_gammel wrote: post #78
zahlman wrote: 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.

Well, 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.

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

#82

Post by KPGv2 »

beej71 wrote: post #47
KPGv2 wrote: post #39

Earlier quoted context omitted.

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/*.j…

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

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

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

#83

Post by akoboldfrying »

xyzzy_plugh wrote: post #58
akoboldfrying wrote: post #15

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.

> please share the name of software that expects/requires an empty directory and interprets .gitkeep in this way, but chokes on a README file.

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.

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

#84

Post by trelbutate »

rswail wrote: post #56
GreenDolphinSys wrote: post #37

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

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.

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

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

#85

Post by kazinator »

jkubicek wrote: post #17

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.

Dummy empty files such as .keepme were used in CVS repositories for exactly the same purpose, and probably other version controls systems long before Git existed.

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

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

#86

Post by _kst_ »

Aaron2222 wrote: post #43
ekipan wrote: post #16

Earlier quoted context omitted.

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…

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

If you want any kind of non-trivial formatting, use the printf command, not echo.

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

#87

Post by rswail »

trelbutate wrote: post #84
rswail wrote: post #56

Earlier quoted context omitted.

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.

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

Yes, 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.

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

#88

Post by throwaway290 »

GreenDolphinSys wrote: post #37

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

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

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

#90

Post by lucketone »

nickysielicki wrote: post #68
hn92726819 wrote: post #59

Earlier quoted context omitted.

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.

> Having 100 tiny gitignores makes finding out why something is excluded annoying. Our policy is one root level gitgnore and gitkeeps where required. 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.

We could say that practically all problems would work them self out one way or another.

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?

Post reply on HN