为什么使用通配符 (*) 和 git 状态从 gitignore 中排除时未列出 .config 目录？

Question

I know the question is a bit cryptic, I couldn't word it exactly in a single sentence ( might need some help on that ).

I initialized git in my home directory (ie, ~/ , on Arch Linux ) to backup my dot-files (mainly configs). I want to include every file and folder in it except the ones starting with a . (like .config/ and .bashrc ).

So I made a .gitignore file whose contents are:

# Ignore everything
*

# Except these files and folders
!.*

But the problem is when I list all the untracked files ( git status ), it doesn't list the .config/ directory for some reason. I tried playing around with .gitignore and adding

!*/

shows all directories including .config/ and also Documents , Downloads etc, which I don't want to include.

And instead adding

!.*/

shows every other directory that starts with a . like .cache/ , .vim/ etc. But for some reason the .config/ doesn't show up.

I even tried

!.config/

and

!.config

it doesn't work. The only thing that works is !*/ (all directories, which is not what I want)

Any way to solve this. Its really annoying.

[Kinda Solved]: edit: it was a bug

After some playing around I figured a way around it. I don't know if I can call it exactly a solution but it works and this is how my .gitignore looks like:

# Ignore everything
*

# Except these files and folders
!.*
!.*/*

And it works, when I run git status it includes all files and directories starting with a . including .config/ and some others which I didn't notice wasn't shown earlier along with .config/ . Check my comment below if you wanna try to figure out (or help me to figure out) why this works.

Answer 1

TL;DR

After the bug fix, you'll want what you put in your "kinda solved" section, or something similar. I think you'll want what I put in my "bottom line" section, really:

/*
!/.*

Long

As jthill noted in a comment , there is a bug in the .gitignore wildcard handling in Git 2.34.0, which will be fixed in 2.34.1. In this case I think the bug is making your wildcarding work better than it would otherwise, though.

The first lines:

# Ignore everything
*

do just what they claim: ignore everything . All files and folders (directories) are ignored. Subsequent lines insert exceptions. But hang on a moment, what does ignored really mean? To get there, we must note what Git's index (or staging area ) is and how Git makes new commits from the index / staging-area.

The index, or staging area, in Git, is a central and crucial concept. Trying to use Git without understanding what the index is doing is a bit like trying to pilot an airplane without understanding what the wings and engine are for. ¹ So: the index is all about the next commit you plan to make . If you never make any new commits, you don't really need to know about it, but if you do want to make new commits, you need to know this. ²

When you first extract some commit, in order to use and work on it, Git fills in its index from that commit, so that the index contains all the files from that commit. From this point onward, everything you are doing in your working tree, in the pursuit of making a new commit, is irrelevant to Git . That is, it's irrelevant up until you tell Git that you'd like Git to copy updated and/or new files into Git's index.

The git add command is about updating Git's index. The files you name to git add , with git add file1 file2 for instance, are to be copied into Git's index. If there's already a copy of those two files, those copies get booted out of the index, replaced with the updated ones. If not, those files are newly added to the index.

Once a file is in the index , you can replace it at any time: any .gitignore entry is irrelevant at this point. You can also remove it from the index , with git rm , or by using git add after removing the working tree copy: either one will remove the index copy. Now it's no longer in the index and the .gitignore entries are back in play.

You can use an en-masse git add , as in git add. or git add * , ³ to have Git scan directories and files and add them for you. When you do this, Git will skip certain directories and/or files if it can, and this is an area where .gitignore really comes into play.

---

¹ "Why should I care about those? I only care about getting my passengers and cargo from point A to point B, and those are inside the plane, not out on the wings."

² To extend the plane analogy a bit more: if you're just planning to use the fuselage as a house, then indeed, you don't need to care about the engines and wings.

³ Note that in Unix-like shells, git add * is quite different from git add. because the shell will expand * for Git: Git never sees the literal asterisk. When the shell expands * , it does so with dot-files excluded, by default at least (bash in particular has a control knob to change this behavior). In some CLIs, the literal asterisk * gets through to Git, and then Git will expand * , and now it can act like git add. if Git wants it to. But it's easier to type in git add. (no SHIFT key required) so that's what I always do anyway, which removes the difference in the first place.

---

How Git scans the working tree

If you run git add. or equivalent (see footnote 3 again), Git will:

1. Open the directory . .
2. Open and read any .gitignore file at this level, adding (appending) these rules to the ignore rules. (These rules then get dropped when we finish this directory.)
3. Read this directory: it contains the names of files and sub-directories ("folders", if you prefer that term).
4. Check each file and folder name as we read them, against all the ignore rules that are in effect right now. Note that some rules apply only to directories / folders , and others apply to both folders and files . The folder-only rules are those that end with a slash. Also, some rules are "positive" (do ignore) and some are "negative" (do not ignore). The negative rules are the ones starting with ! .

Git finds the last applicable rule , whatever that is, in the current set of rules, and then obeys that rule. So first, let's define which rules apply to which directory-scan results, and then what the various rules do.

A rule in a .gitignore can be:

• a simple text string with no slashes, such as generated.file ;
• a text string with a trailing slash, but no other slashes: somedir/ ;
• a text string with a leading or embedded slash, with or without a trailing slash: /foo , a/b , /foo/ , a/b/ , and so on; or
• any of the above with various glob -style wildcard characters.

These can all be negated: if a rule starts with ! it's negated, and we strip off the ! and then use the remaining tests. The two keys tests are these:

• Does the entry end with a literal / ? If so, it applies only to directories / folders. Ignore that slash while answering the remaining question.
• Does the entry begin with or contain a slash / character? (The one at the end does not count here.) If so, this entry is anchored or rooted (I like the term anchored myself, but I've seen both terms used).

An anchored entry matches only a file or folder name found at this level . That is, /foo or foo/bar won't match sub/foo or sub/foo/bar , only ./foo and ./foo/bar , where . is the directory (folder) that Git is scanning right now . This means that if the entry has several levels— foo/bar or one/two/three for instance—Git will have to remember to apply this entry when it gets around to scanning bar in foo , or two in one and three in one/two . So we do have to consider "higher level" rules. But since lower level rules get appended , a lower level .gitignore can cancel out the higher level one if it wants to.

An un-anchored entry applies here and—unless overridden—in every sub-directory as well . That is, if we do have ./one/two/three , Git will presumably open and read one to find two , and then open and read two to find three , all while still working on the current directory . Meanwhile any un-anchored entry from this .gitignore will apply within the one and one/two directories, and within one/two/three if that's a directory, and so on.

So, there's already a lot to think about. Now we throw in glob matches.

The usual glob is * : people write foo*bar or *.pyc or whatever. Git allows ** as well, with meaning similar to that in bash: zero or more directories. (I've found ** in Git to be weird and in my opinion slightly buggy, where it sometimes seems to mean "one or more" instead of "zero or more", so I recommend avoiding ** if possible. It's hard to reason about, so it's generally not a great idea in the first place, and Git's ignore rules mostly eliminate any need for ** . So if you are going to use it, test it carefully and be prepared to have it shift on you in some future Git, in case the one-or-more?bug? gets fixed, or affects your use case, or whatever.)

Let's suppose, then, that we have these two entries:

*
!.*

Git opens and reads . and finds the following names:

dir
file
.dir
.file

where dir and .dir are directories (folders) and file and .file are non-directories (files).

The * rule matches all four names. The ..* rule matches the last two names. The ..* rule is later in the .gitignore file, so it overrides the * rule. Git therefore "sees" .dir and .file .

Since .file is a file, this means that git add. "sees" it. It will check whether .file needs to be git add -ed to displace the existing .file file, or added to the index.

Since dir and file are excluded, this scanning pass doesn't see them, and does not try to git add either one. Since dir itself is a directory (not a file), it's never in the index itself. There may be a file in the index named dir/thing , and Git will check to see if that should be updated by this git add. , but Git won't scan dir to see if there are other files in dir .

Since file is an excluded file, the scanning pass does not see it. But if file already exists in the index, Git will check to see if it should be updated by this git add. , even though it didn't get scanned here. In other words, these "existing files already in the index" checks happen outside (either before or after) the "scan the directories" pass.

Meanwhile, since .dir isn't excluded, Git now opens and reads .dir , recursively:

• Git checks for a .dir/.gitignore (the .gitignore that applies to entries found in .dir ). If that exists, Git appends those rules.
• Git scans .dir recursively, using all the same methods. Then it's done scanning .dir so Git removes the appended rules.

Let's look now at the rules Git has in effect as it scans .dir .

The appended-to rules

If there is a .dir/.gitignore , Git opens and reads it and appends to the existing rules. If not, we still have the same set of rules in effect:

*     (positive wildcard: ignore every name)
!.*   (negative wildcard: don't ignore dot-names)

What's in .dir ? Let's say we have:

file1
dir1
.file2
.dir2

The name file1 matches * so it gets ignored . Git won't git add it to the index if it's not already there. Similarly, dir1 matches * , so it gets ignored . Git won't even scan it to see if there are any files there.

The name .file2 matches * , but also matches .* , so the override negative entry is the rule that applies: Git will git add.dir/.file2 . The name .dir2 has the same features, so the override applies and Git will open and read .dir/.dir2 . This goes through the same recursion as before: Git looks for .dir/.dir2/.gitignore to append rules, and will use the appended-to rules while scanning .dir/.dir2 , and then drop back to our own .dir/.gitignore -appended rule set while continuing to scan .dir , and then return from this recursion level and drop the .dir/.gitignore rules.

The bottom line

In the end, the trick here is that we want the * rule to apply only at the top level . Once we get into, say, .foo/ , we don't want to ignore .foo/main_config and .foo/secondary_config . So we want * to apply only at the top level .

Using:

# Ignore everything
*

# Except these files and folders
!.*
!.*/*

gets us closer: we ignore everything, but then—via the negative rules ..* and ..*/* —we carefully don't ignore .foo and the like. Once we get into .foo , we carefully don't ignore .foo/main_config .

The bug, or possible bug, depending on what you really do want, here is... well, suppose we have .foo/thing1/config and .foo/thing2/config . The .*/* pattern contains an embedded slash , which means it is anchored . It matches .foo/thing1 , so that directory gets scanned. But it doesn't match .foo/thing1/config .

We could try something like:

!.*/*
!.*/**/

I particularly hate this one because ** is so tough to reason about. We could also write:

!.*/*
!.*/*/
!.*/**/

in case the ** "one or more" bug bites us (I don't think it will, but it's a consideration). But it's simplest to anchor the original globs , by writing:

/*
!/.*

This makes the top level .gitignore rules apply only to top-level work-tree entries . Sub-level .gitignore files, if they exist, can establish sub-level rules and do not need to override any top-level rules, because the top-level rules already don't apply at any sub-level , thanks to anchoring.