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