]>
Commit | Line | Data |
---|---|---|
1 | git-rm(1) | |
2 | ========= | |
3 | ||
4 | NAME | |
5 | ---- | |
6 | git-rm - Remove files from the working tree and from the index | |
7 | ||
8 | SYNOPSIS | |
9 | -------- | |
10 | [verse] | |
11 | 'git rm' [-f | --force] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>... | |
12 | ||
13 | DESCRIPTION | |
14 | ----------- | |
15 | Remove files from the index, or from the working tree and the index. | |
16 | `git rm` will not remove a file from just your working directory. | |
17 | (There is no option to remove a file only from the working tree | |
18 | and yet keep it in the index; use `/bin/rm` if you want to do that.) | |
19 | The files being removed have to be identical to the tip of the branch, | |
20 | and no updates to their contents can be staged in the index, | |
21 | though that default behavior can be overridden with the `-f` option. | |
22 | When `--cached` is given, the staged content has to | |
23 | match either the tip of the branch or the file on disk, | |
24 | allowing the file to be removed from just the index. | |
25 | ||
26 | ||
27 | OPTIONS | |
28 | ------- | |
29 | <file>...:: | |
30 | Files to remove. Fileglobs (e.g. `*.c`) can be given to | |
31 | remove all matching files. If you want Git to expand | |
32 | file glob characters, you may need to shell-escape them. | |
33 | A leading directory name | |
34 | (e.g. `dir` to remove `dir/file1` and `dir/file2`) can be | |
35 | given to remove all files in the directory, and recursively | |
36 | all sub-directories, | |
37 | but this requires the `-r` option to be explicitly given. | |
38 | ||
39 | -f:: | |
40 | --force:: | |
41 | Override the up-to-date check. | |
42 | ||
43 | -n:: | |
44 | --dry-run:: | |
45 | Don't actually remove any file(s). Instead, just show | |
46 | if they exist in the index and would otherwise be removed | |
47 | by the command. | |
48 | ||
49 | -r:: | |
50 | Allow recursive removal when a leading directory name is | |
51 | given. | |
52 | ||
53 | \--:: | |
54 | This option can be used to separate command-line options from | |
55 | the list of files, (useful when filenames might be mistaken | |
56 | for command-line options). | |
57 | ||
58 | --cached:: | |
59 | Use this option to unstage and remove paths only from the index. | |
60 | Working tree files, whether modified or not, will be | |
61 | left alone. | |
62 | ||
63 | --ignore-unmatch:: | |
64 | Exit with a zero status even if no files matched. | |
65 | ||
66 | -q:: | |
67 | --quiet:: | |
68 | `git rm` normally outputs one line (in the form of an `rm` command) | |
69 | for each file removed. This option suppresses that output. | |
70 | ||
71 | ||
72 | DISCUSSION | |
73 | ---------- | |
74 | ||
75 | The <file> list given to the command can be exact pathnames, | |
76 | file glob patterns, or leading directory names. The command | |
77 | removes only the paths that are known to Git. Giving the name of | |
78 | a file that you have not told Git about does not remove that file. | |
79 | ||
80 | File globbing matches across directory boundaries. Thus, given | |
81 | two directories `d` and `d2`, there is a difference between | |
82 | using `git rm 'd*'` and `git rm 'd/*'`, as the former will | |
83 | also remove all of directory `d2`. | |
84 | ||
85 | REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM | |
86 | -------------------------------------------------------- | |
87 | There is no option for `git rm` to remove from the index only | |
88 | the paths that have disappeared from the filesystem. However, | |
89 | depending on the use case, there are several ways that can be | |
90 | done. | |
91 | ||
92 | Using ``git commit -a'' | |
93 | ~~~~~~~~~~~~~~~~~~~~~~~ | |
94 | If you intend that your next commit should record all modifications | |
95 | of tracked files in the working tree and record all removals of | |
96 | files that have been removed from the working tree with `rm` | |
97 | (as opposed to `git rm`), use `git commit -a`, as it will | |
98 | automatically notice and record all removals. You can also have a | |
99 | similar effect without committing by using `git add -u`. | |
100 | ||
101 | Using ``git add -A'' | |
102 | ~~~~~~~~~~~~~~~~~~~~ | |
103 | When accepting a new code drop for a vendor branch, you probably | |
104 | want to record both the removal of paths and additions of new paths | |
105 | as well as modifications of existing paths. | |
106 | ||
107 | Typically you would first remove all tracked files from the working | |
108 | tree using this command: | |
109 | ||
110 | ---------------- | |
111 | git ls-files -z | xargs -0 rm -f | |
112 | ---------------- | |
113 | ||
114 | and then untar the new code in the working tree. Alternately | |
115 | you could 'rsync' the changes into the working tree. | |
116 | ||
117 | After that, the easiest way to record all removals, additions, and | |
118 | modifications in the working tree is: | |
119 | ||
120 | ---------------- | |
121 | git add -A | |
122 | ---------------- | |
123 | ||
124 | See linkgit:git-add[1]. | |
125 | ||
126 | Other ways | |
127 | ~~~~~~~~~~ | |
128 | If all you really want to do is to remove from the index the files | |
129 | that are no longer present in the working tree (perhaps because | |
130 | your working tree is dirty so that you cannot use `git commit -a`), | |
131 | use the following command: | |
132 | ||
133 | ---------------- | |
134 | git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached | |
135 | ---------------- | |
136 | ||
137 | SUBMODULES | |
138 | ---------- | |
139 | Only submodules using a gitfile (which means they were cloned | |
140 | with a Git version 1.7.8 or newer) will be removed from the work | |
141 | tree, as their repository lives inside the .git directory of the | |
142 | superproject. If a submodule (or one of those nested inside it) | |
143 | still uses a .git directory, `git rm` will move the submodules | |
144 | git directory into the superprojects git directory to protect | |
145 | the submodule's history. If it exists the submodule.<name> section | |
146 | in the linkgit:gitmodules[5] file will also be removed and that file | |
147 | will be staged (unless --cached or -n are used). | |
148 | ||
149 | A submodule is considered up to date when the HEAD is the same as | |
150 | recorded in the index, no tracked files are modified and no untracked | |
151 | files that aren't ignored are present in the submodules work tree. | |
152 | Ignored files are deemed expendable and won't stop a submodule's work | |
153 | tree from being removed. | |
154 | ||
155 | If you only want to remove the local checkout of a submodule from your | |
156 | work tree without committing the removal, use linkgit:git-submodule[1] `deinit` | |
157 | instead. Also see linkgit:gitsubmodules[7] for details on submodule removal. | |
158 | ||
159 | EXAMPLES | |
160 | -------- | |
161 | `git rm Documentation/\*.txt`:: | |
162 | Removes all `*.txt` files from the index that are under the | |
163 | `Documentation` directory and any of its subdirectories. | |
164 | + | |
165 | Note that the asterisk `*` is quoted from the shell in this | |
166 | example; this lets Git, and not the shell, expand the pathnames | |
167 | of files and subdirectories under the `Documentation/` directory. | |
168 | ||
169 | `git rm -f git-*.sh`:: | |
170 | Because this example lets the shell expand the asterisk | |
171 | (i.e. you are listing the files explicitly), it | |
172 | does not remove `subdir/git-foo.sh`. | |
173 | ||
174 | BUGS | |
175 | ---- | |
176 | Each time a superproject update removes a populated submodule | |
177 | (e.g. when switching between commits before and after the removal) a | |
178 | stale submodule checkout will remain in the old location. Removing the | |
179 | old directory is only safe when it uses a gitfile, as otherwise the | |
180 | history of the submodule will be deleted too. This step will be | |
181 | obsolete when recursive submodule update has been implemented. | |
182 | ||
183 | SEE ALSO | |
184 | -------- | |
185 | linkgit:git-add[1] | |
186 | ||
187 | GIT | |
188 | --- | |
189 | Part of the linkgit:git[1] suite |