Prevent git from removing local directory which is in git ignore for initial git setup

Question

I have a wordpress project in which I want to setup git on a server. I also want to add the wp-content/plugins directory in .gitignore so it remains unaffected during the git setup. But when I did this on my local, the plugins folder gets deleted.

I tried this

1. Reset master to initial commit to get the plugins folder and contents and which doesnt have plugins in gitignore

2. git rm --cached -r wp-content/plugins/

3. git pull to get the commit which deleted the plugins folder and puts the plugins in gitignore.

But it still deletes the plugins folder.

How do I prevent git from deleting the plugins and also the uploads folder? The plugins folder also should not be in the master branch

Answer 1

How do I prevent git from deleting [these] folder[s]?

Put some file(s) in them.

What's going on here

Git is not really interested in directories / folders (you called them directories first, then later, folders, so I use both terms here). Git is interested in, and stores, files. As far as Git is concerned, files have—or can have—long-ish names with parts that your OS insists on treating in folder-ish ways. For instance, Git might store a file named wp-content/plugins/file.ext. Your OS demands that this be stored as a file named file.ext in a folder named plugins in a folder named wp-content. That's your OS's problem, not Git's, but it becomes Git's problem the moment Git goes to extract the file named wp-content/plugins/file.ext from some commit, to an ordinary file on your computer.

At that point, Git will create wp-content if needed, then create wp-content/plugins if needed, so that it can create the file that, to Git, is named wp-content/plugins/file.ext. Git did not store these folders anywhere. It stored the file wp-content/plugins/file.ext (in a commit) and then you told it "take that commit and make it available to me" so then it created the two directories because your OS insists on this folder-and-file structure.

Because the OS insists, Git will create directories / folders on demand. By the same token, when Git removes a committed file—because you're switching away from that commit, to some other commit that lacks that file—Git will clean up after itself by removing a directory / folder, if that's the last file that forces Git to accommodate the OS by having that directory / folder exist.

Git cannot and therefore will not remove the directory / folder if some other sub-directory/folder or some file exists within the directory. So if you have any untracked files in there, for instance, Git won't touch the directory.

Note that git clean -df will remove empty directories from the work-tree, whether or not Git created them. This is all due to the fact that Git does not store information about directories/folders in its index. The index is the thing from which Git builds new commits. The index is very central to Git: it's where merges really happen; it's where new commits are built; and it caches information about an extracted commit, to make Git run fast.

In general, between one Git command and the next, Git doesn't remember any directories it created. All it does is:

• remove a commit's files from the index, and if you've told it to update your work-tree, remove those same files from the work-tree; and
• load a commit into the index, and if you've told it to update your work-tree, replace those files with their committed (and now index copy) versions.

Because the index does not keep track of directories—only files, with long names like wp-content/plugins/file.ext—Git literally cannot store an empty folder.¹ That's why it uses this "create when needed, remove when removing the last file" trick.

Because Git uses the "remove a work-tree folder when removing its last file", the only thing that stops Git from removing such a directory/folder is to leave some file in it. This can be a committed file, such as an empty .gitignore or empty .keep or whatever you like, or just some untracked file. If it's some untracked file, Git itself won't create the directory either: you will have to do that.

See the footnote link for the way to use an empty submodule instead of a dummy .gitignore, but I will note that if I were doing this I'd just use a dummy .gitignore (probably not an empty one, but rather one with one line reading *).

---

¹It can, however, store a submodule, via a gitlink, and a gitlink can point to a repository that has no files. Hence, the empty submodule does actually work to store an empty directory! It's kind of a shame that the index can't store a mode 40000 directory, because if it could, Git could store and manage empty folders, without resorting to the "use the empty submodule" trick.