|
| 1 | +SPECIFYING PATHSPECS |
| 2 | +-------------------- |
| 3 | + |
| 4 | +Pathspecs are used on the command line of "git ls-files", "git |
| 5 | +ls-tree", "git add", "git grep", "git diff", "git checkout", |
| 6 | +and many other commands to |
| 7 | +limit the scope of operations to some subset of the tree or |
| 8 | +working tree. See the documentation of each command for whether |
| 9 | +paths are relative to the current directory or toplevel. The |
| 10 | +pathspec syntax is as follows: |
| 11 | + |
| 12 | +* any path matches itself |
| 13 | +* the pathspec up to the last slash represents a |
| 14 | + directory prefix. The scope of that pathspec is |
| 15 | + limited to that subtree. |
| 16 | +* the rest of the pathspec is a pattern for the remainder |
| 17 | + of the pathname. Paths relative to the directory |
| 18 | + prefix will be matched against that pattern using fnmatch(3); |
| 19 | + in particular, '*' and '?' _can_ match directory separators. |
| 20 | +
|
| 21 | +For example, Documentation/*.jpg will match all .jpg files |
| 22 | +in the Documentation subtree, |
| 23 | +including Documentation/chapter_1/figure_1.jpg. |
| 24 | +
|
| 25 | +A pathspec that begins with a colon `:` has special meaning. In the |
| 26 | +short form, the leading colon `:` is followed by zero or more "magic |
| 27 | +signature" letters (which optionally is terminated by another colon `:`), |
| 28 | +and the remainder is the pattern to match against the path. |
| 29 | +The "magic signature" consists of ASCII symbols that are neither |
| 30 | +alphanumeric, glob, regex special characters nor colon. |
| 31 | +The optional colon that terminates the "magic signature" can be |
| 32 | +omitted if the pattern begins with a character that does not belong to |
| 33 | +"magic signature" symbol set and is not a colon. |
| 34 | +
|
| 35 | +In the long form, the leading colon `:` is followed by an open |
| 36 | +parenthesis `(`, a comma-separated list of zero or more "magic words", |
| 37 | +and a close parentheses `)`, and the remainder is the pattern to match |
| 38 | +against the path. |
| 39 | +
|
| 40 | +A pathspec with only a colon means "there is no pathspec". This form |
| 41 | +should not be combined with other pathspec. |
| 42 | +
|
| 43 | +top;; |
| 44 | + The magic word `top` (magic signature: `/`) makes the pattern |
| 45 | + match from the root of the working tree, even when you are |
| 46 | + running the command from inside a subdirectory. |
| 47 | +
|
| 48 | +literal;; |
| 49 | + Wildcards in the pattern such as `*` or `?` are treated |
| 50 | + as literal characters. |
| 51 | + |
| 52 | +icase;; |
| 53 | + Case insensitive match. |
| 54 | + |
| 55 | +glob;; |
| 56 | + Git treats the pattern as a shell glob suitable for |
| 57 | + consumption by fnmatch(3) with the FNM_PATHNAME flag: |
| 58 | + wildcards in the pattern will not match a / in the pathname. |
| 59 | + For example, "Documentation/{asterisk}.html" matches |
| 60 | + "Documentation/git.html" but not "Documentation/ppc/ppc.html" |
| 61 | + or "tools/perf/Documentation/perf.html". |
| 62 | ++ |
| 63 | +Two consecutive asterisks ("`**`") in patterns matched against |
| 64 | +full pathname may have special meaning: |
| 65 | + |
| 66 | + - A leading "`**`" followed by a slash means match in all |
| 67 | + directories. For example, "`**/foo`" matches file or directory |
| 68 | + "`foo`" anywhere. "`**/foo/bar`" matches file or directory "`bar`" |
| 69 | + anywhere that is directly under directory "`foo`". |
| 70 | + |
| 71 | + - A trailing "`/**`" matches everything inside. For example, |
| 72 | + "`abc/**`" matches all files inside directory "abc", relative |
| 73 | + to the location of the `.gitignore` file, with infinite depth. |
| 74 | + |
| 75 | + - A slash followed by two consecutive asterisks then a slash |
| 76 | + matches zero or more directories. For example, "`a/**/b`" |
| 77 | + matches "`a/b`", "`a/x/b`", "`a/x/y/b`" and so on. |
| 78 | + |
| 79 | + - Other consecutive asterisks are considered invalid. |
| 80 | + |
| 81 | ++ |
| 82 | +Glob magic is incompatible with literal magic. |
| 83 | + |
| 84 | +attr;; |
| 85 | +After `attr:` comes a space separated list of "attribute |
| 86 | +requirements", all of which must be met in order for the |
| 87 | +path to be considered a match; this is in addition to the |
| 88 | +usual non-magic pathspec pattern matching. |
| 89 | +See linkgit:gitattributes[5]. |
| 90 | ++ |
| 91 | +Each of the attribute requirements for the path takes one of |
| 92 | +these forms: |
| 93 | + |
| 94 | +- "`ATTR`" requires that the attribute `ATTR` be set. |
| 95 | + |
| 96 | +- "`-ATTR`" requires that the attribute `ATTR` be unset. |
| 97 | + |
| 98 | +- "`ATTR=VALUE`" requires that the attribute `ATTR` be |
| 99 | + set to the string `VALUE`. |
| 100 | + |
| 101 | +- "`!ATTR`" requires that the attribute `ATTR` be |
| 102 | + unspecified. |
| 103 | + |
| 104 | ++ |
| 105 | +Note that when matching against a tree object, attributes are still |
| 106 | +obtained from working tree, not from the given tree object. |
| 107 | + |
| 108 | +exclude;; |
| 109 | + After a path matches any non-exclude pathspec, it will be run |
| 110 | + through all exclude pathspecs (magic signature: `!` or its |
| 111 | + synonym `^`). If it matches, the path is ignored. When there |
| 112 | + is no non-exclude pathspec, the exclusion is applied to the |
| 113 | + result set as if invoked without any pathspec. |
0 commit comments