Git fork
1git-add(1)
2==========
3
4NAME
5----
6git-add - Add file contents to the index
7
8SYNOPSIS
9--------
10[synopsis]
11git add [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p]
12 [--edit | -e] [--[no-]all | -A | --[no-]ignore-removal | [--update | -u]] [--sparse]
13 [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize]
14 [--chmod=(+|-)x] [--pathspec-from-file=<file> [--pathspec-file-nul]]
15 [--] [<pathspec>...]
16
17DESCRIPTION
18-----------
19Add contents of new or changed files to the index. The "index" (also
20known as the "staging area") is what you use to prepare the contents of
21the next commit.
22
23When you run `git commit` without any other arguments, it will only
24commit staged changes. For example, if you've edited `file.c` and want
25to commit your changes to that file, you can run:
26
27 git add file.c
28 git commit
29
30You can also add only part of your changes to a file with `git add -p`.
31
32This command can be performed multiple times before a commit. It only
33adds the content of the specified file(s) at the time the add command is
34run; if you want subsequent changes included in the next commit, then
35you must run `git add` again to add the new content to the index.
36
37The `git status` command can be used to obtain a summary of which
38files have changes that are staged for the next commit.
39
40The `git add` command will not add ignored files by default. You can
41use the `--force` option to add ignored files. If you specify the exact
42filename of an ignored file, `git add` will fail with a list of ignored
43files. Otherwise it will silently ignore the file.
44
45Please see linkgit:git-commit[1] for alternative ways to add content to a
46commit.
47
48
49OPTIONS
50-------
51`<pathspec>...`::
52 Files to add content from. Fileglobs (e.g. `*.c`) can
53 be given to add all matching files. Also a
54 leading directory name (e.g. `dir` to add `dir/file1`
55 and `dir/file2`) can be given to update the index to
56 match the current state of the directory as a whole (e.g.
57 specifying `dir` will record not just a file `dir/file1`
58 modified in the working tree, a file `dir/file2` added to
59 the working tree, but also a file `dir/file3` removed from
60 the working tree). Note that older versions of Git used
61 to ignore removed files; use `--no-all` option if you want
62 to add modified or new files but ignore removed ones.
63+
64For more details about the _<pathspec>_ syntax, see the 'pathspec' entry
65in linkgit:gitglossary[7].
66
67`-n`::
68`--dry-run`::
69 Don't actually add the file(s), just show if they exist and/or will
70 be ignored.
71
72`-v`::
73`--verbose`::
74 Be verbose.
75
76`-f`::
77`--force`::
78 Allow adding otherwise ignored files.
79
80`--sparse`::
81 Allow updating index entries outside of the sparse-checkout cone.
82 Normally, `git add` refuses to update index entries whose paths do
83 not fit within the sparse-checkout cone, since those files might
84 be removed from the working tree without warning. See
85 linkgit:git-sparse-checkout[1] for more details.
86
87`-i`::
88`--interactive`::
89 Add modified contents in the working tree interactively to
90 the index. Optional path arguments may be supplied to limit
91 operation to a subset of the working tree. See ``Interactive
92 mode'' for details.
93
94`-p`::
95`--patch`::
96 Interactively choose hunks of patch between the index and the
97 work tree and add them to the index. This gives the user a chance
98 to review the difference before adding modified contents to the
99 index.
100+
101This effectively runs `add --interactive`, but bypasses the
102initial command menu and directly jumps to the `patch` subcommand.
103See ``Interactive mode'' for details.
104
105include::diff-context-options.adoc[]
106
107`-e`::
108`--edit`::
109 Open the diff vs. the index in an editor and let the user
110 edit it. After the editor was closed, adjust the hunk headers
111 and apply the patch to the index.
112+
113The intent of this option is to pick and choose lines of the patch to
114apply, or even to modify the contents of lines to be staged. This can be
115quicker and more flexible than using the interactive hunk selector.
116However, it is easy to confuse oneself and create a patch that does not
117apply to the index. See EDITING PATCHES below.
118
119`-u`::
120`--update`::
121 Update the index just where it already has an entry matching
122 _<pathspec>_. This removes as well as modifies index entries to
123 match the working tree, but adds no new files.
124+
125If no _<pathspec>_ is given when `-u` option is used, all
126tracked files in the entire working tree are updated (old versions
127of Git used to limit the update to the current directory and its
128subdirectories).
129
130`-A`::
131`--all`::
132`--no-ignore-removal`::
133 Update the index not only where the working tree has a file
134 matching _<pathspec>_ but also where the index already has an
135 entry. This adds, modifies, and removes index entries to
136 match the working tree.
137+
138If no _<pathspec>_ is given when `-A` option is used, all
139files in the entire working tree are updated (old versions
140of Git used to limit the update to the current directory and its
141subdirectories).
142
143`--no-all`::
144`--ignore-removal`::
145 Update the index by adding new files that are unknown to the
146 index and files modified in the working tree, but ignore
147 files that have been removed from the working tree. This
148 option is a no-op when no _<pathspec>_ is used.
149+
150This option is primarily to help users who are used to older
151versions of Git, whose `git add <pathspec>...` was a synonym
152for `git add --no-all <pathspec>...`, i.e. ignored removed files.
153
154`-N`::
155`--intent-to-add`::
156 Record only the fact that the path will be added later. An entry
157 for the path is placed in the index with no content. This is
158 useful for, among other things, showing the unstaged content of
159 such files with `git diff` and committing them with `git commit
160 -a`.
161
162`--refresh`::
163 Don't add the file(s), but only refresh their stat()
164 information in the index.
165
166`--ignore-errors`::
167 If some files could not be added because of errors indexing
168 them, do not abort the operation, but continue adding the
169 others. The command shall still exit with non-zero status.
170 The configuration variable `add.ignoreErrors` can be set to
171 true to make this the default behaviour.
172
173`--ignore-missing`::
174 This option can only be used together with `--dry-run`. By using
175 this option the user can check if any of the given files would
176 be ignored, no matter if they are already present in the work
177 tree or not.
178
179`--no-warn-embedded-repo`::
180 By default, `git add` will warn when adding an embedded
181 repository to the index without using `git submodule add` to
182 create an entry in `.gitmodules`. This option will suppress the
183 warning (e.g., if you are manually performing operations on
184 submodules).
185
186`--renormalize`::
187 Apply the "clean" process freshly to all tracked files to
188 forcibly add them again to the index. This is useful after
189 changing `core.autocrlf` configuration or the `text` attribute
190 in order to correct files added with wrong _CRLF/LF_ line endings.
191 This option implies `-u`. Lone CR characters are untouched, thus
192 while a _CRLF_ cleans to _LF_, a _CRCRLF_ sequence is only partially
193 cleaned to _CRLF_.
194
195`--chmod=(+|-)x`::
196 Override the executable bit of the added files. The executable
197 bit is only changed in the index, the files on disk are left
198 unchanged.
199
200`--pathspec-from-file=<file>`::
201 Pathspec is passed in _<file>_ instead of commandline args. If
202 _<file>_ is exactly `-` then standard input is used. Pathspec
203 elements are separated by _LF_ or _CR/LF_. Pathspec elements can be
204 quoted as explained for the configuration variable `core.quotePath`
205 (see linkgit:git-config[1]). See also `--pathspec-file-nul` and
206 global `--literal-pathspecs`.
207
208`--pathspec-file-nul`::
209 Only meaningful with `--pathspec-from-file`. Pathspec elements are
210 separated with _NUL_ character and all other characters are taken
211 literally (including newlines and quotes).
212
213`--`::
214 This option can be used to separate command-line options from
215 the list of files, (useful when filenames might be mistaken
216 for command-line options).
217
218
219EXAMPLES
220--------
221
222* Adds content from all ++*.txt++ files under `Documentation` directory
223 and its subdirectories:
224+
225------------
226$ git add Documentation/\*.txt
227------------
228+
229Note that the asterisk ++*++ is quoted from the shell in this
230example; this lets the command include the files from
231subdirectories of `Documentation/` directory.
232
233* Considers adding content from all ++git-*.sh++ scripts:
234+
235------------
236$ git add git-*.sh
237------------
238+
239Because this example lets the shell expand the asterisk (i.e. you are
240listing the files explicitly), it does not consider
241`subdir/git-foo.sh`.
242
243INTERACTIVE MODE
244----------------
245When the command enters the interactive mode, it shows the
246output of the 'status' subcommand, and then goes into its
247interactive command loop.
248
249The command loop shows the list of subcommands available, and
250gives a prompt "What now> ". In general, when the prompt ends
251with a single '>', you can pick only one of the choices given
252and type return, like this:
253
254------------
255 *** Commands ***
256 1: status 2: update 3: revert 4: add untracked
257 5: patch 6: diff 7: quit 8: help
258 What now> 1
259------------
260
261You also could say `s` or `sta` or `status` above as long as the
262choice is unique.
263
264The main command loop has 6 subcommands (plus help and quit).
265
266status::
267
268 This shows the change between `HEAD` and index (i.e. what will be
269 committed if you say `git commit`), and between index and
270 working tree files (i.e. what you could stage further before
271 `git commit` using `git add`) for each path. A sample output
272 looks like this:
273+
274------------
275 staged unstaged path
276 1: binary nothing foo.png
277 2: +403/-35 +1/-1 add-interactive.c
278------------
279+
280It shows that `foo.png` has differences from `HEAD` (but that is
281binary so line count cannot be shown) and there is no
282difference between indexed copy and the working tree
283version (if the working tree version were also different,
284'binary' would have been shown in place of 'nothing'). The
285other file, `add-interactive.c`, has 403 lines added
286and 35 lines deleted if you commit what is in the index, but
287working tree file has further modifications (one addition and
288one deletion).
289
290update::
291
292 This shows the status information and issues an "Update>>"
293 prompt. When the prompt ends with double '>>', you can
294 make more than one selection, concatenated with whitespace or
295 comma. Also you can say ranges. E.g. "2-5 7,9" to choose
296 2,3,4,5,7,9 from the list. If the second number in a range is
297 omitted, all remaining patches are taken. E.g. "7-" to choose
298 7,8,9 from the list. You can say '*' to choose everything.
299+
300What you chose are then highlighted with '*',
301like this:
302+
303------------
304 staged unstaged path
305 1: binary nothing foo.png
306* 2: +403/-35 +1/-1 add-interactive.c
307------------
308+
309To remove selection, prefix the input with `-`
310like this:
311+
312------------
313Update>> -2
314------------
315+
316After making the selection, answer with an empty line to stage the
317contents of working tree files for selected paths in the index.
318
319revert::
320
321 This has a very similar UI to 'update', and the staged
322 information for selected paths are reverted to that of the
323 HEAD version. Reverting new paths makes them untracked.
324
325add untracked::
326
327 This has a very similar UI to 'update' and
328 'revert', and lets you add untracked paths to the index.
329
330patch::
331
332 This lets you choose one path out of a 'status' like selection.
333 After choosing the path, it presents the diff between the index
334 and the working tree file and asks you if you want to stage
335 the change of each hunk. You can select one of the following
336 options and type return:
337
338 y - stage this hunk
339 n - do not stage this hunk
340 q - quit; do not stage this hunk or any of the remaining ones
341 a - stage this hunk and all later hunks in the file
342 d - do not stage this hunk or any of the later hunks in the file
343 g - select a hunk to go to
344 / - search for a hunk matching the given regex
345 j - go to the next undecided hunk, roll over at the bottom
346 J - go to the next hunk, roll over at the bottom
347 k - go to the previous undecided hunk, roll over at the top
348 K - go to the previous hunk, roll over at the top
349 s - split the current hunk into smaller hunks
350 e - manually edit the current hunk
351 p - print the current hunk
352 P - print the current hunk using the pager
353 ? - print help
354+
355After deciding the fate for all hunks, if there is any hunk
356that was chosen, the index is updated with the selected hunks.
357+
358You can omit having to type return here, by setting the configuration
359variable `interactive.singleKey` to `true`.
360
361diff::
362
363 This lets you review what will be committed (i.e. between
364 `HEAD` and index).
365
366
367EDITING PATCHES
368---------------
369
370Invoking `git add -e` or selecting `e` from the interactive hunk
371selector will open a patch in your editor; after the editor exits, the
372result is applied to the index. You are free to make arbitrary changes
373to the patch, but note that some changes may have confusing results, or
374even result in a patch that cannot be applied. If you want to abort the
375operation entirely (i.e., stage nothing new in the index), simply delete
376all lines of the patch. The list below describes some common things you
377may see in a patch, and which editing operations make sense on them.
378
379--
380added content::
381
382Added content is represented by lines beginning with "{plus}". You can
383prevent staging any addition lines by deleting them.
384
385removed content::
386
387Removed content is represented by lines beginning with "-". You can
388prevent staging their removal by converting the "-" to a " " (space).
389
390modified content::
391
392Modified content is represented by "-" lines (removing the old content)
393followed by "{plus}" lines (adding the replacement content). You can
394prevent staging the modification by converting "-" lines to " ", and
395removing "{plus}" lines. Beware that modifying only half of the pair is
396likely to introduce confusing changes to the index.
397--
398
399There are also more complex operations that can be performed. But beware
400that because the patch is applied only to the index and not the working
401tree, the working tree will appear to "undo" the change in the index.
402For example, introducing a new line into the index that is in neither
403the `HEAD` nor the working tree will stage the new line for commit, but
404the line will appear to be reverted in the working tree.
405
406Avoid using these constructs, or do so with extreme caution.
407
408--
409removing untouched content::
410
411Content which does not differ between the index and working tree may be
412shown on context lines, beginning with a " " (space). You can stage
413context lines for removal by converting the space to a "-". The
414resulting working tree file will appear to re-add the content.
415
416modifying existing content::
417
418One can also modify context lines by staging them for removal (by
419converting " " to "-") and adding a "{plus}" line with the new content.
420Similarly, one can modify "{plus}" lines for existing additions or
421modifications. In all cases, the new modification will appear reverted
422in the working tree.
423
424new content::
425
426You may also add new content that does not exist in the patch; simply
427add new lines, each starting with "{plus}". The addition will appear
428reverted in the working tree.
429--
430
431There are also several operations which should be avoided entirely, as
432they will make the patch impossible to apply:
433
434* adding context (" ") or removal ("-") lines
435* deleting context or removal lines
436* modifying the contents of context or removal lines
437
438CONFIGURATION
439-------------
440
441include::includes/cmd-config-section-all.adoc[]
442
443:git-add: 1
444include::config/add.adoc[]
445
446SEE ALSO
447--------
448linkgit:git-status[1]
449linkgit:git-rm[1]
450linkgit:git-reset[1]
451linkgit:git-mv[1]
452linkgit:git-commit[1]
453linkgit:git-update-index[1]
454
455GIT
456---
457Part of the linkgit:git[1] suite