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