doc/source/en/TortoiseGit/git_doc/git-commit.xml

   1 <?xml version="1.0" encoding="UTF-8"?>\r
   2 <!DOCTYPE sect2 SYSTEM "../../../dtd/dblite.dtd">\r
   3 \r
   4 <sect2 lang="en" id="git-commit(1)">\r
   5     <title>git-commit(1)</title>\r
   6     <date>2024-07-02</date>\r
   7 <revhistory><revision><date>2024-07-02</date></revision></revhistory>\r
   8 <indexterm>\r
   9 <primary>git-commit(1)</primary>\r
  10 </indexterm>\r
  11 <simplesect id="git-commit(1)__name">\r
  12 <title>NAME</title>\r
  13 <simpara>git-commit - Record changes to the repository</simpara>\r
  14 </simplesect>\r
  15 <simplesect id="git-commit(1)__synopsis">\r
  16 <title>SYNOPSIS</title>\r
  17 <blockquote>\r
  18 <literallayout><emphasis>git commit</emphasis> [-a | --interactive | --patch] [-s] [-v] [-u&lt;mode&gt;] [--amend]\r
  19            [--dry-run] [(-c | -C | --squash) &lt;commit&gt; | --fixup [(amend|reword):]&lt;commit&gt;)]\r
  20            [-F &lt;file&gt; | -m &lt;msg&gt;] [--reset-author] [--allow-empty]\r
  21            [--allow-empty-message] [--no-verify] [-e] [--author=&lt;author&gt;]\r
  22            [--date=&lt;date&gt;] [--cleanup=&lt;mode&gt;] [--[no-]status]\r
  23            [-i | -o] [--pathspec-from-file=&lt;file&gt; [--pathspec-file-nul]]\r
  24            [(--trailer &lt;token&gt;[(=|:)&lt;value&gt;])&#8230;] [-S[&lt;keyid&gt;]]\r
  25            [--] [&lt;pathspec&gt;&#8230;]</literallayout>\r
  26 </blockquote>\r
  27 </simplesect>\r
  28 <simplesect id="git-commit(1)__description">\r
  29 <title>DESCRIPTION</title>\r
  30 <simpara>Create a new commit containing the current contents of the index and\r
  31 the given log message describing the changes. The new commit is a\r
  32 direct child of HEAD, usually the tip of the current branch, and the\r
  33 branch is updated to point to it (unless no branch is associated with\r
  34 the working tree, in which case HEAD is "detached" as described in\r
  35 <xref linkend="git-checkout(1)" />).</simpara>\r
  36 <simpara>The content to be committed can be specified in several ways:</simpara>\r
  37 <orderedlist numeration="arabic">\r
  38 <listitem>\r
  39 <simpara>\r
  40 by using <xref linkend="git-add(1)" /> to incrementally "add" changes to the\r
  41    index before using the <emphasis>commit</emphasis> command (Note: even modified files\r
  42    must be "added");\r
  43 </simpara>\r
  44 </listitem>\r
  45 <listitem>\r
  46 <simpara>\r
  47 by using <xref linkend="git-rm(1)" /> to remove files from the working tree\r
  48    and the index, again before using the <emphasis>commit</emphasis> command;\r
  49 </simpara>\r
  50 </listitem>\r
  51 <listitem>\r
  52 <simpara>\r
  53 by listing files as arguments to the <emphasis>commit</emphasis> command\r
  54    (without --interactive or --patch switch), in which\r
  55    case the commit will ignore changes staged in the index, and instead\r
  56    record the current content of the listed files (which must already\r
  57    be known to Git);\r
  58 </simpara>\r
  59 </listitem>\r
  60 <listitem>\r
  61 <simpara>\r
  62 by using the -a switch with the <emphasis>commit</emphasis> command to automatically\r
  63    "add" changes from all known files (i.e. all files that are already\r
  64    listed in the index) and to automatically "rm" files in the index\r
  65    that have been removed from the working tree, and then perform the\r
  66    actual commit;\r
  67 </simpara>\r
  68 </listitem>\r
  69 <listitem>\r
  70 <simpara>\r
  71 by using the --interactive or --patch switches with the <emphasis>commit</emphasis> command\r
  72    to decide one by one which files or hunks should be part of the commit\r
  73    in addition to contents in the index,\r
  74    before finalizing the operation. See the Interactive Mode section of\r
  75    <xref linkend="git-add(1)" /> to learn how to operate these modes.\r
  76 </simpara>\r
  77 </listitem>\r
  78 </orderedlist>\r
  79 <simpara>The <emphasis>--dry-run</emphasis> option can be used to obtain a\r
  80 summary of what is included by any of the above for the next\r
  81 commit by giving the same set of parameters (options and paths).</simpara>\r
  82 <simpara>If you make a commit and then find a mistake immediately after\r
  83 that, you can recover from it with <emphasis>git reset</emphasis>.</simpara>\r
  84 </simplesect>\r
  85 <simplesect id="git-commit(1)__options">\r
  86 <title>OPTIONS</title>\r
  87 <variablelist>\r
  88 <varlistentry>\r
  89 <term>\r
  90 -a\r
  91 </term>\r
  92 <term>\r
  93 --all\r
  94 </term>\r
  95 <listitem>\r
  96 <simpara>\r
  97         Tell the command to automatically stage files that have\r
  98         been modified and deleted, but new files you have not\r
  99         told Git about are not affected.\r
 100 </simpara>\r
 101 </listitem>\r
 102 </varlistentry>\r
 103 <varlistentry>\r
 104 <term>\r
 105 -p\r
 106 </term>\r
 107 <term>\r
 108 --patch\r
 109 </term>\r
 110 <listitem>\r
 111 <simpara>\r
 112         Use the interactive patch selection interface to choose\r
 113         which changes to commit. See <xref linkend="git-add(1)" /> for\r
 114         details.\r
 115 </simpara>\r
 116 </listitem>\r
 117 </varlistentry>\r
 118 <varlistentry>\r
 119 <term>\r
 120 -C &lt;commit&gt;\r
 121 </term>\r
 122 <term>\r
 123 --reuse-message=&lt;commit&gt;\r
 124 </term>\r
 125 <listitem>\r
 126 <simpara>\r
 127         Take an existing commit object, and reuse the log message\r
 128         and the authorship information (including the timestamp)\r
 129         when creating the commit.\r
 130 </simpara>\r
 131 </listitem>\r
 132 </varlistentry>\r
 133 <varlistentry>\r
 134 <term>\r
 135 -c &lt;commit&gt;\r
 136 </term>\r
 137 <term>\r
 138 --reedit-message=&lt;commit&gt;\r
 139 </term>\r
 140 <listitem>\r
 141 <simpara>\r
 142         Like <emphasis>-C</emphasis>, but with <emphasis>-c</emphasis> the editor is invoked, so that\r
 143         the user can further edit the commit message.\r
 144 </simpara>\r
 145 </listitem>\r
 146 </varlistentry>\r
 147 <varlistentry>\r
 148 <term>\r
 149 --fixup=[(amend|reword):]&lt;commit&gt;\r
 150 </term>\r
 151 <listitem>\r
 152 <simpara>\r
 153         Create a new commit which "fixes up" <emphasis>&lt;commit&gt;</emphasis> when applied with\r
 154         <emphasis>git rebase --autosquash</emphasis>. Plain <emphasis>--fixup=&lt;commit&gt;</emphasis> creates a\r
 155         "fixup!" commit which changes the content of <emphasis>&lt;commit&gt;</emphasis> but leaves\r
 156         its log message untouched. <emphasis>--fixup=amend:&lt;commit&gt;</emphasis> is similar but\r
 157         creates an "amend!" commit which also replaces the log message of\r
 158         <emphasis>&lt;commit&gt;</emphasis> with the log message of the "amend!" commit.\r
 159         <emphasis>--fixup=reword:&lt;commit&gt;</emphasis> creates an "amend!" commit which\r
 160         replaces the log message of <emphasis>&lt;commit&gt;</emphasis> with its own log message\r
 161         but makes no changes to the content of <emphasis>&lt;commit&gt;</emphasis>.\r
 162 </simpara>\r
 163 <simpara>The commit created by plain <emphasis>--fixup=&lt;commit&gt;</emphasis> has a subject\r
 164 composed of "fixup!" followed by the subject line from &lt;commit&gt;,\r
 165 and is recognized specially by <emphasis>git rebase --autosquash</emphasis>. The <emphasis>-m</emphasis>\r
 166 option may be used to supplement the log message of the created\r
 167 commit, but the additional commentary will be thrown away once the\r
 168 "fixup!" commit is squashed into <emphasis>&lt;commit&gt;</emphasis> by\r
 169 <emphasis>git rebase --autosquash</emphasis>.</simpara>\r
 170 <simpara>The commit created by <emphasis>--fixup=amend:&lt;commit&gt;</emphasis> is similar but its\r
 171 subject is instead prefixed with "amend!". The log message of\r
 172 &lt;commit&gt; is copied into the log message of the "amend!" commit and\r
 173 opened in an editor so it can be refined. When <emphasis>git rebase\r
 174 --autosquash</emphasis> squashes the "amend!" commit into <emphasis>&lt;commit&gt;</emphasis>, the\r
 175 log message of <emphasis>&lt;commit&gt;</emphasis> is replaced by the refined log message\r
 176 from the "amend!" commit. It is an error for the "amend!" commit's\r
 177 log message to be empty unless <emphasis>--allow-empty-message</emphasis> is\r
 178 specified.</simpara>\r
 179 <simpara><emphasis>--fixup=reword:&lt;commit&gt;</emphasis> is shorthand for <emphasis>--fixup=amend:&lt;commit&gt;\r
 180 --only</emphasis>. It creates an "amend!" commit with only a log message\r
 181 (ignoring any changes staged in the index). When squashed by <emphasis>git\r
 182 rebase --autosquash</emphasis>, it replaces the log message of <emphasis>&lt;commit&gt;</emphasis>\r
 183 without making any other changes.</simpara>\r
 184 <simpara>Neither "fixup!" nor "amend!" commits change authorship of\r
 185 <emphasis>&lt;commit&gt;</emphasis> when applied by <emphasis>git rebase --autosquash</emphasis>.\r
 186 See <xref linkend="git-rebase(1)" /> for details.</simpara>\r
 187 </listitem>\r
 188 </varlistentry>\r
 189 <varlistentry>\r
 190 <term>\r
 191 --squash=&lt;commit&gt;\r
 192 </term>\r
 193 <listitem>\r
 194 <simpara>\r
 195         Construct a commit message for use with <emphasis>rebase --autosquash</emphasis>.\r
 196         The commit message subject line is taken from the specified\r
 197         commit with a prefix of "squash! ".  Can be used with additional\r
 198         commit message options (<emphasis>-m</emphasis>/<emphasis>-c</emphasis>/<emphasis>-C</emphasis>/<emphasis>-F</emphasis>). See\r
 199         <xref linkend="git-rebase(1)" /> for details.\r
 200 </simpara>\r
 201 </listitem>\r
 202 </varlistentry>\r
 203 <varlistentry>\r
 204 <term>\r
 205 --reset-author\r
 206 </term>\r
 207 <listitem>\r
 208 <simpara>\r
 209         When used with -C/-c/--amend options, or when committing after a\r
 210         conflicting cherry-pick, declare that the authorship of the\r
 211         resulting commit now belongs to the committer. This also renews\r
 212         the author timestamp.\r
 213 </simpara>\r
 214 </listitem>\r
 215 </varlistentry>\r
 216 <varlistentry>\r
 217 <term>\r
 218 --short\r
 219 </term>\r
 220 <listitem>\r
 221 <simpara>\r
 222         When doing a dry-run, give the output in the short-format. See\r
 223         <xref linkend="git-status(1)" /> for details. Implies <emphasis>--dry-run</emphasis>.\r
 224 </simpara>\r
 225 </listitem>\r
 226 </varlistentry>\r
 227 <varlistentry>\r
 228 <term>\r
 229 --branch\r
 230 </term>\r
 231 <listitem>\r
 232 <simpara>\r
 233         Show the branch and tracking info even in short-format.\r
 234 </simpara>\r
 235 </listitem>\r
 236 </varlistentry>\r
 237 <varlistentry>\r
 238 <term>\r
 239 --porcelain\r
 240 </term>\r
 241 <listitem>\r
 242 <simpara>\r
 243         When doing a dry-run, give the output in a porcelain-ready\r
 244         format. See <xref linkend="git-status(1)" /> for details. Implies\r
 245         <emphasis>--dry-run</emphasis>.\r
 246 </simpara>\r
 247 </listitem>\r
 248 </varlistentry>\r
 249 <varlistentry>\r
 250 <term>\r
 251 --long\r
 252 </term>\r
 253 <listitem>\r
 254 <simpara>\r
 255         When doing a dry-run, give the output in the long-format.\r
 256         Implies <emphasis>--dry-run</emphasis>.\r
 257 </simpara>\r
 258 </listitem>\r
 259 </varlistentry>\r
 260 <varlistentry>\r
 261 <term>\r
 262 -z\r
 263 </term>\r
 264 <term>\r
 265 --null\r
 266 </term>\r
 267 <listitem>\r
 268 <simpara>\r
 269         When showing <emphasis>short</emphasis> or <emphasis>porcelain</emphasis> status output, print the\r
 270         filename verbatim and terminate the entries with NUL, instead of LF.\r
 271         If no format is given, implies the <emphasis>--porcelain</emphasis> output format.\r
 272         Without the <emphasis>-z</emphasis> option, filenames with "unusual" characters are\r
 273         quoted as explained for the configuration variable <emphasis>core.quotePath</emphasis>\r
 274         (see <xref linkend="git-config(1)" />).\r
 275 </simpara>\r
 276 </listitem>\r
 277 </varlistentry>\r
 278 <varlistentry>\r
 279 <term>\r
 280 -F &lt;file&gt;\r
 281 </term>\r
 282 <term>\r
 283 --file=&lt;file&gt;\r
 284 </term>\r
 285 <listitem>\r
 286 <simpara>\r
 287         Take the commit message from the given file.  Use <emphasis>-</emphasis> to\r
 288         read the message from the standard input.\r
 289 </simpara>\r
 290 </listitem>\r
 291 </varlistentry>\r
 292 <varlistentry>\r
 293 <term>\r
 294 --author=&lt;author&gt;\r
 295 </term>\r
 296 <listitem>\r
 297 <simpara>\r
 298         Override the commit author. Specify an explicit author using the\r
 299         standard <emphasis>A U Thor &lt;author@example.com&gt;</emphasis> format. Otherwise &lt;author&gt;\r
 300         is assumed to be a pattern and is used to search for an existing\r
 301         commit by that author (i.e. rev-list --all -i --author=&lt;author&gt;);\r
 302         the commit author is then copied from the first such commit found.\r
 303 </simpara>\r
 304 </listitem>\r
 305 </varlistentry>\r
 306 <varlistentry>\r
 307 <term>\r
 308 --date=&lt;date&gt;\r
 309 </term>\r
 310 <listitem>\r
 311 <simpara>\r
 312         Override the author date used in the commit.\r
 313 </simpara>\r
 314 </listitem>\r
 315 </varlistentry>\r
 316 <varlistentry>\r
 317 <term>\r
 318 -m &lt;msg&gt;\r
 319 </term>\r
 320 <term>\r
 321 --message=&lt;msg&gt;\r
 322 </term>\r
 323 <listitem>\r
 324 <simpara>\r
 325         Use the given &lt;msg&gt; as the commit message.\r
 326         If multiple <emphasis>-m</emphasis> options are given, their values are\r
 327         concatenated as separate paragraphs.\r
 328 </simpara>\r
 329 <simpara>The <emphasis>-m</emphasis> option is mutually exclusive with <emphasis>-c</emphasis>, <emphasis>-C</emphasis>, and <emphasis>-F</emphasis>.</simpara>\r
 330 </listitem>\r
 331 </varlistentry>\r
 332 <varlistentry>\r
 333 <term>\r
 334 -t &lt;file&gt;\r
 335 </term>\r
 336 <term>\r
 337 --template=&lt;file&gt;\r
 338 </term>\r
 339 <listitem>\r
 340 <simpara>\r
 341         When editing the commit message, start the editor with the\r
 342         contents in the given file.  The <emphasis>commit.template</emphasis> configuration\r
 343         variable is often used to give this option implicitly to the\r
 344         command.  This mechanism can be used by projects that want to\r
 345         guide participants with some hints on what to write in the message\r
 346         in what order.  If the user exits the editor without editing the\r
 347         message, the commit is aborted.  This has no effect when a message\r
 348         is given by other means, e.g. with the <emphasis>-m</emphasis> or <emphasis>-F</emphasis> options.\r
 349 </simpara>\r
 350 </listitem>\r
 351 </varlistentry>\r
 352 <varlistentry>\r
 353 <term>\r
 354 -s\r
 355 </term>\r
 356 <term>\r
 357 --signoff\r
 358 </term>\r
 359 <term>\r
 360 --no-signoff\r
 361 </term>\r
 362 <listitem>\r
 363 <simpara>\r
 364         Add a <emphasis>Signed-off-by</emphasis> trailer by the committer at the end of the commit\r
 365         log message.  The meaning of a signoff depends on the project\r
 366         to which you're committing.  For example, it may certify that\r
 367         the committer has the rights to submit the work under the\r
 368         project's license or agrees to some contributor representation,\r
 369         such as a Developer Certificate of Origin.\r
 370         (See <ulink url="https://developercertificate.org">https://developercertificate.org</ulink> for the one used by the\r
 371         Linux kernel and Git projects.)  Consult the documentation or\r
 372         leadership of the project to which you're contributing to\r
 373         understand how the signoffs are used in that project.\r
 374 </simpara>\r
 375 <simpara>The --no-signoff option can be used to countermand an earlier --signoff\r
 376 option on the command line.</simpara>\r
 377 </listitem>\r
 378 </varlistentry>\r
 379 <varlistentry>\r
 380 <term>\r
 381 --trailer &lt;token&gt;[(=|:)&lt;value&gt;]\r
 382 </term>\r
 383 <listitem>\r
 384 <simpara>\r
 385         Specify a (&lt;token&gt;, &lt;value&gt;) pair that should be applied as a\r
 386         trailer. (e.g. <emphasis>git commit --trailer "Signed-off-by:C O Mitter \\r
 387         &lt;committer@example.com&gt;" --trailer "Helped-by:C O Mitter \\r
 388         &lt;committer@example.com&gt;"</emphasis> will add the "Signed-off-by" trailer\r
 389         and the "Helped-by" trailer to the commit message.)\r
 390         The <emphasis>trailer.*</emphasis> configuration variables\r
 391         (<xref linkend="git-interpret-trailers(1)" />) can be used to define if\r
 392         a duplicated trailer is omitted, where in the run of trailers\r
 393         each trailer would appear, and other details.\r
 394 </simpara>\r
 395 </listitem>\r
 396 </varlistentry>\r
 397 <varlistentry>\r
 398 <term>\r
 399 -n\r
 400 </term>\r
 401 <term>\r
 402 --[no-]verify\r
 403 </term>\r
 404 <listitem>\r
 405 <simpara>\r
 406         By default, the pre-commit and commit-msg hooks are run.\r
 407         When any of <emphasis>--no-verify</emphasis> or <emphasis>-n</emphasis> is given, these are bypassed.\r
 408         See also <xref linkend="githooks(5)" />.\r
 409 </simpara>\r
 410 </listitem>\r
 411 </varlistentry>\r
 412 <varlistentry>\r
 413 <term>\r
 414 --allow-empty\r
 415 </term>\r
 416 <listitem>\r
 417 <simpara>\r
 418         Usually recording a commit that has the exact same tree as its\r
 419         sole parent commit is a mistake, and the command prevents you\r
 420         from making such a commit.  This option bypasses the safety, and\r
 421         is primarily for use by foreign SCM interface scripts.\r
 422 </simpara>\r
 423 </listitem>\r
 424 </varlistentry>\r
 425 <varlistentry>\r
 426 <term>\r
 427 --allow-empty-message\r
 428 </term>\r
 429 <listitem>\r
 430 <simpara>\r
 431        Like --allow-empty this command is primarily for use by foreign\r
 432        SCM interface scripts. It allows you to create a commit with an\r
 433        empty commit message without using plumbing commands like\r
 434        <xref linkend="git-commit-tree(1)" />.\r
 435 </simpara>\r
 436 </listitem>\r
 437 </varlistentry>\r
 438 <varlistentry>\r
 439 <term>\r
 440 --cleanup=&lt;mode&gt;\r
 441 </term>\r
 442 <listitem>\r
 443 <simpara>\r
 444         This option determines how the supplied commit message should be\r
 445         cleaned up before committing.  The <emphasis>&lt;mode&gt;</emphasis> can be <emphasis>strip</emphasis>,\r
 446         <emphasis>whitespace</emphasis>, <emphasis>verbatim</emphasis>, <emphasis>scissors</emphasis> or <emphasis>default</emphasis>.\r
 447 </simpara>\r
 448 <variablelist>\r
 449 <varlistentry>\r
 450 <term>\r
 451 strip\r
 452 </term>\r
 453 <listitem>\r
 454 <simpara>\r
 455         Strip leading and trailing empty lines, trailing whitespace,\r
 456         commentary and collapse consecutive empty lines.\r
 457 </simpara>\r
 458 </listitem>\r
 459 </varlistentry>\r
 460 <varlistentry>\r
 461 <term>\r
 462 whitespace\r
 463 </term>\r
 464 <listitem>\r
 465 <simpara>\r
 466         Same as <emphasis>strip</emphasis> except #commentary is not removed.\r
 467 </simpara>\r
 468 </listitem>\r
 469 </varlistentry>\r
 470 <varlistentry>\r
 471 <term>\r
 472 verbatim\r
 473 </term>\r
 474 <listitem>\r
 475 <simpara>\r
 476         Do not change the message at all.\r
 477 </simpara>\r
 478 </listitem>\r
 479 </varlistentry>\r
 480 <varlistentry>\r
 481 <term>\r
 482 scissors\r
 483 </term>\r
 484 <listitem>\r
 485 <simpara>\r
 486         Same as <emphasis>whitespace</emphasis> except that everything from (and including)\r
 487         the line found below is truncated, if the message is to be edited.\r
 488         "<emphasis>#</emphasis>" can be customized with core.commentChar.\r
 489 </simpara>\r
 490 <literallayout class="monospaced"># ------------------------ &gt;8 ------------------------</literallayout>\r
 491 </listitem>\r
 492 </varlistentry>\r
 493 <varlistentry>\r
 494 <term>\r
 495 default\r
 496 </term>\r
 497 <listitem>\r
 498 <simpara>\r
 499         Same as <emphasis>strip</emphasis> if the message is to be edited.\r
 500         Otherwise <emphasis>whitespace</emphasis>.\r
 501 </simpara>\r
 502 </listitem>\r
 503 </varlistentry>\r
 504 </variablelist>\r
 505 <simpara>The default can be changed by the <emphasis>commit.cleanup</emphasis> configuration\r
 506 variable (see <xref linkend="git-config(1)" />).</simpara>\r
 507 </listitem>\r
 508 </varlistentry>\r
 509 <varlistentry>\r
 510 <term>\r
 511 -e\r
 512 </term>\r
 513 <term>\r
 514 --edit\r
 515 </term>\r
 516 <listitem>\r
 517 <simpara>\r
 518         The message taken from file with <emphasis>-F</emphasis>, command line with\r
 519         <emphasis>-m</emphasis>, and from commit object with <emphasis>-C</emphasis> are usually used as\r
 520         the commit log message unmodified. This option lets you\r
 521         further edit the message taken from these sources.\r
 522 </simpara>\r
 523 </listitem>\r
 524 </varlistentry>\r
 525 <varlistentry>\r
 526 <term>\r
 527 --no-edit\r
 528 </term>\r
 529 <listitem>\r
 530 <simpara>\r
 531         Use the selected commit message without launching an editor.\r
 532         For example, <emphasis>git commit --amend --no-edit</emphasis> amends a commit\r
 533         without changing its commit message.\r
 534 </simpara>\r
 535 </listitem>\r
 536 </varlistentry>\r
 537 <varlistentry>\r
 538 <term>\r
 539 --amend\r
 540 </term>\r
 541 <listitem>\r
 542 <simpara>\r
 543         Replace the tip of the current branch by creating a new\r
 544         commit. The recorded tree is prepared as usual (including\r
 545         the effect of the <emphasis>-i</emphasis> and <emphasis>-o</emphasis> options and explicit\r
 546         pathspec), and the message from the original commit is used\r
 547         as the starting point, instead of an empty message, when no\r
 548         other message is specified from the command line via options\r
 549         such as <emphasis>-m</emphasis>, <emphasis>-F</emphasis>, <emphasis>-c</emphasis>, etc.  The new commit has the same\r
 550         parents and author as the current one (the <emphasis>--reset-author</emphasis>\r
 551         option can countermand this).\r
 552 </simpara>\r
 553 <simpara>It is a rough equivalent for:</simpara>\r
 554 <screen>        $ git reset --soft HEAD^\r
 555         $ ... do something else to come up with the right tree ...\r
 556         $ git commit -c ORIG_HEAD</screen>\r
 557 <simpara>but can be used to amend a merge commit.</simpara>\r
 558 <simpara>You should understand the implications of rewriting history if you\r
 559 amend a commit that has already been published.  (See the "RECOVERING\r
 560 FROM UPSTREAM REBASE" section in <xref linkend="git-rebase(1)" />.)</simpara>\r
 561 </listitem>\r
 562 </varlistentry>\r
 563 <varlistentry>\r
 564 <term>\r
 565 --no-post-rewrite\r
 566 </term>\r
 567 <listitem>\r
 568 <simpara>\r
 569         Bypass the post-rewrite hook.\r
 570 </simpara>\r
 571 </listitem>\r
 572 </varlistentry>\r
 573 <varlistentry>\r
 574 <term>\r
 575 -i\r
 576 </term>\r
 577 <term>\r
 578 --include\r
 579 </term>\r
 580 <listitem>\r
 581 <simpara>\r
 582         Before making a commit out of staged contents so far,\r
 583         stage the contents of paths given on the command line\r
 584         as well.  This is usually not what you want unless you\r
 585         are concluding a conflicted merge.\r
 586 </simpara>\r
 587 </listitem>\r
 588 </varlistentry>\r
 589 <varlistentry>\r
 590 <term>\r
 591 -o\r
 592 </term>\r
 593 <term>\r
 594 --only\r
 595 </term>\r
 596 <listitem>\r
 597 <simpara>\r
 598         Make a commit by taking the updated working tree contents\r
 599         of the paths specified on the\r
 600         command line, disregarding any contents that have been\r
 601         staged for other paths. This is the default mode of operation of\r
 602         <emphasis>git commit</emphasis> if any paths are given on the command line,\r
 603         in which case this option can be omitted.\r
 604         If this option is specified together with <emphasis>--amend</emphasis>, then\r
 605         no paths need to be specified, which can be used to amend\r
 606         the last commit without committing changes that have\r
 607         already been staged. If used together with <emphasis>--allow-empty</emphasis>\r
 608         paths are also not required, and an empty commit will be created.\r
 609 </simpara>\r
 610 </listitem>\r
 611 </varlistentry>\r
 612 <varlistentry>\r
 613 <term>\r
 614 --pathspec-from-file=&lt;file&gt;\r
 615 </term>\r
 616 <listitem>\r
 617 <simpara>\r
 618         Pathspec is passed in <emphasis>&lt;file&gt;</emphasis> instead of commandline args. If\r
 619         <emphasis>&lt;file&gt;</emphasis> is exactly <emphasis>-</emphasis> then standard input is used. Pathspec\r
 620         elements are separated by LF or CR/LF. Pathspec elements can be\r
 621         quoted as explained for the configuration variable <emphasis>core.quotePath</emphasis>\r
 622         (see <xref linkend="git-config(1)" />). See also <emphasis>--pathspec-file-nul</emphasis> and\r
 623         global <emphasis>--literal-pathspecs</emphasis>.\r
 624 </simpara>\r
 625 </listitem>\r
 626 </varlistentry>\r
 627 <varlistentry>\r
 628 <term>\r
 629 --pathspec-file-nul\r
 630 </term>\r
 631 <listitem>\r
 632 <simpara>\r
 633         Only meaningful with <emphasis>--pathspec-from-file</emphasis>. Pathspec elements are\r
 634         separated with NUL character and all other characters are taken\r
 635         literally (including newlines and quotes).\r
 636 </simpara>\r
 637 </listitem>\r
 638 </varlistentry>\r
 639 <varlistentry>\r
 640 <term>\r
 641 -u[&lt;mode&gt;]\r
 642 </term>\r
 643 <term>\r
 644 --untracked-files[=&lt;mode&gt;]\r
 645 </term>\r
 646 <listitem>\r
 647 <simpara>\r
 648         Show untracked files.\r
 649 </simpara>\r
 650 <simpara>The mode parameter is optional (defaults to <emphasis>all</emphasis>), and is used to\r
 651 specify the handling of untracked files; when -u is not used, the\r
 652 default is <emphasis>normal</emphasis>, i.e. show untracked files and directories.</simpara>\r
 653 <simpara>The possible options are:</simpara>\r
 654 <itemizedlist>\r
 655 <listitem>\r
 656 <simpara>\r
 657 <emphasis>no</emphasis>     - Show no untracked files\r
 658 </simpara>\r
 659 </listitem>\r
 660 <listitem>\r
 661 <simpara>\r
 662 <emphasis>normal</emphasis> - Shows untracked files and directories\r
 663 </simpara>\r
 664 </listitem>\r
 665 <listitem>\r
 666 <simpara>\r
 667 <emphasis>all</emphasis>    - Also shows individual files in untracked directories.\r
 668 </simpara>\r
 669 </listitem>\r
 670 </itemizedlist>\r
 671 <simpara>All usual spellings for Boolean value <emphasis>true</emphasis> are taken as <emphasis>normal</emphasis>\r
 672 and <emphasis>false</emphasis> as <emphasis>no</emphasis>.\r
 673 The default can be changed using the status.showUntrackedFiles\r
 674 configuration variable documented in <xref linkend="git-config(1)" />.</simpara>\r
 675 </listitem>\r
 676 </varlistentry>\r
 677 <varlistentry>\r
 678 <term>\r
 679 -v\r
 680 </term>\r
 681 <term>\r
 682 --verbose\r
 683 </term>\r
 684 <listitem>\r
 685 <simpara>\r
 686         Show unified diff between the HEAD commit and what\r
 687         would be committed at the bottom of the commit message\r
 688         template to help the user describe the commit by reminding\r
 689         what changes the commit has.\r
 690         Note that this diff output doesn't have its\r
 691         lines prefixed with <emphasis>#</emphasis>. This diff will not be a part\r
 692         of the commit message. See the <emphasis>commit.verbose</emphasis> configuration\r
 693         variable in <xref linkend="git-config(1)" />.\r
 694 </simpara>\r
 695 <simpara>If specified twice, show in addition the unified diff between\r
 696 what would be committed and the worktree files, i.e. the unstaged\r
 697 changes to tracked files.</simpara>\r
 698 </listitem>\r
 699 </varlistentry>\r
 700 <varlistentry>\r
 701 <term>\r
 702 -q\r
 703 </term>\r
 704 <term>\r
 705 --quiet\r
 706 </term>\r
 707 <listitem>\r
 708 <simpara>\r
 709         Suppress commit summary message.\r
 710 </simpara>\r
 711 </listitem>\r
 712 </varlistentry>\r
 713 <varlistentry>\r
 714 <term>\r
 715 --dry-run\r
 716 </term>\r
 717 <listitem>\r
 718 <simpara>\r
 719         Do not create a commit, but show a list of paths that are\r
 720         to be committed, paths with local changes that will be left\r
 721         uncommitted and paths that are untracked.\r
 722 </simpara>\r
 723 </listitem>\r
 724 </varlistentry>\r
 725 <varlistentry>\r
 726 <term>\r
 727 --status\r
 728 </term>\r
 729 <listitem>\r
 730 <simpara>\r
 731         Include the output of <xref linkend="git-status(1)" /> in the commit\r
 732         message template when using an editor to prepare the commit\r
 733         message.  Defaults to on, but can be used to override\r
 734         configuration variable commit.status.\r
 735 </simpara>\r
 736 </listitem>\r
 737 </varlistentry>\r
 738 <varlistentry>\r
 739 <term>\r
 740 --no-status\r
 741 </term>\r
 742 <listitem>\r
 743 <simpara>\r
 744         Do not include the output of <xref linkend="git-status(1)" /> in the\r
 745         commit message template when using an editor to prepare the\r
 746         default commit message.\r
 747 </simpara>\r
 748 </listitem>\r
 749 </varlistentry>\r
 750 <varlistentry>\r
 751 <term>\r
 752 -S[&lt;keyid&gt;]\r
 753 </term>\r
 754 <term>\r
 755 --gpg-sign[=&lt;keyid&gt;]\r
 756 </term>\r
 757 <term>\r
 758 --no-gpg-sign\r
 759 </term>\r
 760 <listitem>\r
 761 <simpara>\r
 762         GPG-sign commits. The <emphasis>keyid</emphasis> argument is optional and\r
 763         defaults to the committer identity; if specified, it must be\r
 764         stuck to the option without a space. <emphasis>--no-gpg-sign</emphasis> is useful to\r
 765         countermand both <emphasis>commit.gpgSign</emphasis> configuration variable, and\r
 766         earlier <emphasis>--gpg-sign</emphasis>.\r
 767 </simpara>\r
 768 </listitem>\r
 769 </varlistentry>\r
 770 <varlistentry>\r
 771 <term>\r
 772 --\r
 773 </term>\r
 774 <listitem>\r
 775 <simpara>\r
 776         Do not interpret any more arguments as options.\r
 777 </simpara>\r
 778 </listitem>\r
 779 </varlistentry>\r
 780 <varlistentry>\r
 781 <term>\r
 782 &lt;pathspec&gt;&#8230;\r
 783 </term>\r
 784 <listitem>\r
 785 <simpara>\r
 786         When pathspec is given on the command line, commit the contents of\r
 787         the files that match the pathspec without recording the changes\r
 788         already added to the index. The contents of these files are also\r
 789         staged for the next commit on top of what have been staged before.\r
 790 </simpara>\r
 791 <simpara>For more details, see the <emphasis>pathspec</emphasis> entry in <xref linkend="gitglossary(7)" />.</simpara>\r
 792 </listitem>\r
 793 </varlistentry>\r
 794 </variablelist>\r
 795 </simplesect>\r
 796 <simplesect id="git-commit(1)__examples">\r
 797 <title>EXAMPLES</title>\r
 798 <simpara>When recording your own work, the contents of modified files in\r
 799 your working tree are temporarily stored to a staging area\r
 800 called the "index" with <emphasis>git add</emphasis>.  A file can be\r
 801 reverted back, only in the index but not in the working tree,\r
 802 to that of the last commit with <emphasis>git restore --staged &lt;file&gt;</emphasis>,\r
 803 which effectively reverts <emphasis>git add</emphasis> and prevents the changes to\r
 804 this file from participating in the next commit.  After building\r
 805 the state to be committed incrementally with these commands,\r
 806 <emphasis>git commit</emphasis> (without any pathname parameter) is used to record what\r
 807 has been staged so far.  This is the most basic form of the\r
 808 command.  An example:</simpara>\r
 809 <screen>$ edit hello.c\r
 810 $ git rm goodbye.c\r
 811 $ git add hello.c\r
 812 $ git commit</screen>\r
 813 <simpara>Instead of staging files after each individual change, you can\r
 814 tell <emphasis>git commit</emphasis> to notice the changes to the files whose\r
 815 contents are tracked in\r
 816 your working tree and do corresponding <emphasis>git add</emphasis> and <emphasis>git rm</emphasis>\r
 817 for you.  That is, this example does the same as the earlier\r
 818 example if there is no other change in your working tree:</simpara>\r
 819 <screen>$ edit hello.c\r
 820 $ rm goodbye.c\r
 821 $ git commit -a</screen>\r
 822 <simpara>The command <emphasis>git commit -a</emphasis> first looks at your working tree,\r
 823 notices that you have modified hello.c and removed goodbye.c,\r
 824 and performs necessary <emphasis>git add</emphasis> and <emphasis>git rm</emphasis> for you.</simpara>\r
 825 <simpara>After staging changes to many files, you can alter the order the\r
 826 changes are recorded in, by giving pathnames to <emphasis>git commit</emphasis>.\r
 827 When pathnames are given, the command makes a commit that\r
 828 only records the changes made to the named paths:</simpara>\r
 829 <screen>$ edit hello.c hello.h\r
 830 $ git add hello.c hello.h\r
 831 $ edit Makefile\r
 832 $ git commit Makefile</screen>\r
 833 <simpara>This makes a commit that records the modification to <emphasis>Makefile</emphasis>.\r
 834 The changes staged for <emphasis>hello.c</emphasis> and <emphasis>hello.h</emphasis> are not included\r
 835 in the resulting commit.  However, their changes are not lost --\r
 836 they are still staged and merely held back.  After the above\r
 837 sequence, if you do:</simpara>\r
 838 <screen>$ git commit</screen>\r
 839 <simpara>this second commit would record the changes to <emphasis>hello.c</emphasis> and\r
 840 <emphasis>hello.h</emphasis> as expected.</simpara>\r
 841 <simpara>After a merge (initiated by <emphasis>git merge</emphasis> or <emphasis>git pull</emphasis>) stops\r
 842 because of conflicts, cleanly merged\r
 843 paths are already staged to be committed for you, and paths that\r
 844 conflicted are left in unmerged state.  You would have to first\r
 845 check which paths are conflicting with <emphasis>git status</emphasis>\r
 846 and after fixing them manually in your working tree, you would\r
 847 stage the result as usual with <emphasis>git add</emphasis>:</simpara>\r
 848 <screen>$ git status | grep unmerged\r
 849 unmerged: hello.c\r
 850 $ edit hello.c\r
 851 $ git add hello.c</screen>\r
 852 <simpara>After resolving conflicts and staging the result, <emphasis>git ls-files -u</emphasis>\r
 853 would stop mentioning the conflicted path.  When you are done,\r
 854 run <emphasis>git commit</emphasis> to finally record the merge:</simpara>\r
 855 <screen>$ git commit</screen>\r
 856 <simpara>As with the case to record your own changes, you can use <emphasis>-a</emphasis>\r
 857 option to save typing.  One difference is that during a merge\r
 858 resolution, you cannot use <emphasis>git commit</emphasis> with pathnames to\r
 859 alter the order the changes are committed, because the merge\r
 860 should be recorded as a single commit.  In fact, the command\r
 861 refuses to run when given pathnames (but see <emphasis>-i</emphasis> option).</simpara>\r
 862 </simplesect>\r
 863 <simplesect id="git-commit(1)__commit_information">\r
 864 <title>COMMIT INFORMATION</title>\r
 865 <simpara>Author and committer information is taken from the following environment\r
 866 variables, if set:</simpara>\r
 867 <literallayout class="monospaced">GIT_AUTHOR_NAME\r
 868 GIT_AUTHOR_EMAIL\r
 869 GIT_AUTHOR_DATE\r
 870 GIT_COMMITTER_NAME\r
 871 GIT_COMMITTER_EMAIL\r
 872 GIT_COMMITTER_DATE</literallayout>\r
 873 <simpara>(nb "&lt;", "&gt;" and "\n"s are stripped)</simpara>\r
 874 <simpara>The author and committer names are by convention some form of a personal name\r
 875 (that is, the name by which other humans refer to you), although Git does not\r
 876 enforce or require any particular form. Arbitrary Unicode may be used, subject\r
 877 to the constraints listed above. This name has no effect on authentication; for\r
 878 that, see the <emphasis>credential.username</emphasis> variable in <xref linkend="git-config(1)" />.</simpara>\r
 879 <simpara>In case (some of) these environment variables are not set, the information\r
 880 is taken from the configuration items <emphasis>user.name</emphasis> and <emphasis>user.email</emphasis>, or, if not\r
 881 present, the environment variable EMAIL, or, if that is not set,\r
 882 system user name and the hostname used for outgoing mail (taken\r
 883 from <emphasis>/etc/mailname</emphasis> and falling back to the fully qualified hostname when\r
 884 that file does not exist).</simpara>\r
 885 <simpara>The <emphasis>author.name</emphasis> and <emphasis>committer.name</emphasis> and their corresponding email options\r
 886 override <emphasis>user.name</emphasis> and <emphasis>user.email</emphasis> if set and are overridden themselves by\r
 887 the environment variables.</simpara>\r
 888 <simpara>The typical usage is to set just the <emphasis>user.name</emphasis> and <emphasis>user.email</emphasis> variables;\r
 889 the other options are provided for more complex use cases.</simpara>\r
 890 </simplesect>\r
 891 <simplesect id="git-commit(1)__date_formats">\r
 892 <title>DATE FORMATS</title>\r
 893 <simpara>The <emphasis>GIT_AUTHOR_DATE</emphasis> and <emphasis>GIT_COMMITTER_DATE</emphasis> environment variables\r
 894 support the following date formats:</simpara>\r
 895 <variablelist>\r
 896 <varlistentry>\r
 897 <term>\r
 898 Git internal format\r
 899 </term>\r
 900 <listitem>\r
 901 <simpara>\r
 902         It is <emphasis>&lt;unix-timestamp&gt; &lt;time-zone-offset&gt;</emphasis>, where\r
 903         <emphasis>&lt;unix-timestamp&gt;</emphasis> is the number of seconds since the UNIX epoch.\r
 904         <emphasis>&lt;time-zone-offset&gt;</emphasis> is a positive or negative offset from UTC.\r
 905         For example CET (which is 1 hour ahead of UTC) is <emphasis>+0100</emphasis>.\r
 906 </simpara>\r
 907 </listitem>\r
 908 </varlistentry>\r
 909 <varlistentry>\r
 910 <term>\r
 911 RFC 2822\r
 912 </term>\r
 913 <listitem>\r
 914 <simpara>\r
 915         The standard date format as described by RFC 2822, for example\r
 916         <emphasis>Thu, 07 Apr 2005 22:13:13 +0200</emphasis>.\r
 917 </simpara>\r
 918 </listitem>\r
 919 </varlistentry>\r
 920 <varlistentry>\r
 921 <term>\r
 922 ISO 8601\r
 923 </term>\r
 924 <listitem>\r
 925 <simpara>\r
 926         Time and date specified by the ISO 8601 standard, for example\r
 927         <emphasis>2005-04-07T22:13:13</emphasis>. The parser accepts a space instead of the\r
 928         <emphasis>T</emphasis> character as well. Fractional parts of a second will be ignored,\r
 929         for example <emphasis>2005-04-07T22:13:13.019</emphasis> will be treated as\r
 930         <emphasis>2005-04-07T22:13:13</emphasis>.\r
 931 </simpara>\r
 932 <note><simpara>In addition, the date part is accepted in the following formats:\r
 933 <emphasis>YYYY.MM.DD</emphasis>, <emphasis>MM/DD/YYYY</emphasis> and <emphasis>DD.MM.YYYY</emphasis>.</simpara></note>\r
 934 </listitem>\r
 935 </varlistentry>\r
 936 </variablelist>\r
 937 <simpara>In addition to recognizing all date formats above, the <emphasis>--date</emphasis> option\r
 938 will also try to make sense of other, more human-centric date formats,\r
 939 such as relative dates like "yesterday" or "last Friday at noon".</simpara>\r
 940 </simplesect>\r
 941 <simplesect id="git-commit(1)__discussion">\r
 942 <title>DISCUSSION</title>\r
 943 <simpara>Though not required, it's a good idea to begin the commit message\r
 944 with a single short (no more than 50 characters) line summarizing the\r
 945 change, followed by a blank line and then a more thorough description.\r
 946 The text up to the first blank line in a commit message is treated\r
 947 as the commit title, and that title is used throughout Git.\r
 948 For example, <xref linkend="git-format-patch(1)" /> turns a commit into email, and it uses\r
 949 the title on the Subject line and the rest of the commit in the body.</simpara>\r
 950 <simpara>Git is to some extent character encoding agnostic.</simpara>\r
 951 <itemizedlist>\r
 952 <listitem>\r
 953 <simpara>\r
 954 The contents of the blob objects are uninterpreted sequences\r
 955    of bytes.  There is no encoding translation at the core\r
 956    level.\r
 957 </simpara>\r
 958 </listitem>\r
 959 <listitem>\r
 960 <simpara>\r
 961 Path names are encoded in UTF-8 normalization form C. This\r
 962    applies to tree objects, the index file, ref names, as well as\r
 963    path names in command line arguments, environment variables\r
 964    and config files (<emphasis>.git/config</emphasis> (see <xref linkend="git-config(1)" />),\r
 965    <xref linkend="gitignore(5)" />, <xref linkend="gitattributes(5)" /> and\r
 966    <xref linkend="gitmodules(5)" />).\r
 967 </simpara>\r
 968 <simpara>Note that Git at the core level treats path names simply as\r
 969 sequences of non-NUL bytes, there are no path name encoding\r
 970 conversions (except on Mac and Windows). Therefore, using\r
 971 non-ASCII path names will mostly work even on platforms and file\r
 972 systems that use legacy extended ASCII encodings. However,\r
 973 repositories created on such systems will not work properly on\r
 974 UTF-8-based systems (e.g. Linux, Mac, Windows) and vice versa.\r
 975 Additionally, many Git-based tools simply assume path names to\r
 976 be UTF-8 and will fail to display other encodings correctly.</simpara>\r
 977 </listitem>\r
 978 <listitem>\r
 979 <simpara>\r
 980 Commit log messages are typically encoded in UTF-8, but other\r
 981    extended ASCII encodings are also supported. This includes\r
 982    ISO-8859-x, CP125x and many others, but <emphasis>not</emphasis> UTF-16/32,\r
 983    EBCDIC and CJK multi-byte encodings (GBK, Shift-JIS, Big5,\r
 984    EUC-x, CP9xx etc.).\r
 985 </simpara>\r
 986 </listitem>\r
 987 </itemizedlist>\r
 988 <simpara>Although we encourage that the commit log messages are encoded\r
 989 in UTF-8, both the core and Git Porcelain are designed not to\r
 990 force UTF-8 on projects.  If all participants of a particular\r
 991 project find it more convenient to use legacy encodings, Git\r
 992 does not forbid it.  However, there are a few things to keep in\r
 993 mind.</simpara>\r
 994 <orderedlist numeration="arabic">\r
 995 <listitem>\r
 996 <simpara>\r
 997 <emphasis>git commit</emphasis> and <emphasis>git commit-tree</emphasis> issue\r
 998   a warning if the commit log message given to it does not look\r
 999   like a valid UTF-8 string, unless you explicitly say your\r
1000   project uses a legacy encoding.  The way to say this is to\r
1001   have <emphasis>i18n.commitEncoding</emphasis> in <emphasis>.git/config</emphasis> file, like this:\r
1002 </simpara>\r
1003 <screen>[i18n]\r
1004         commitEncoding = ISO-8859-1</screen>\r
1005 <simpara>Commit objects created with the above setting record the value\r
1006 of <emphasis>i18n.commitEncoding</emphasis> in their <emphasis>encoding</emphasis> header.  This is to\r
1007 help other people who look at them later.  Lack of this header\r
1008 implies that the commit log message is encoded in UTF-8.</simpara>\r
1009 </listitem>\r
1010 <listitem>\r
1011 <simpara>\r
1012 <emphasis>git log</emphasis>, <emphasis>git show</emphasis>, <emphasis>git blame</emphasis> and friends look at the\r
1013   <emphasis>encoding</emphasis> header of a commit object, and try to re-code the\r
1014   log message into UTF-8 unless otherwise specified.  You can\r
1015   specify the desired output encoding with\r
1016   <emphasis>i18n.logOutputEncoding</emphasis> in <emphasis>.git/config</emphasis> file, like this:\r
1017 </simpara>\r
1018 <screen>[i18n]\r
1019         logOutputEncoding = ISO-8859-1</screen>\r
1020 <simpara>If you do not have this configuration variable, the value of\r
1021 <emphasis>i18n.commitEncoding</emphasis> is used instead.</simpara>\r
1022 </listitem>\r
1023 </orderedlist>\r
1024 <simpara>Note that we deliberately chose not to re-code the commit log\r
1025 message when a commit is made to force UTF-8 at the commit\r
1026 object level, because re-coding to UTF-8 is not necessarily a\r
1027 reversible operation.</simpara>\r
1028 </simplesect>\r
1029 <simplesect id="git-commit(1)__environment_and_configuration_variables">\r
1030 <title>ENVIRONMENT AND CONFIGURATION VARIABLES</title>\r
1031 <simpara>The editor used to edit the commit log message will be chosen from the\r
1032 <emphasis>GIT_EDITOR</emphasis> environment variable, the core.editor configuration variable, the\r
1033 <emphasis>VISUAL</emphasis> environment variable, or the <emphasis>EDITOR</emphasis> environment variable (in that\r
1034 order).  See <xref linkend="git-var(1)" /> for details.</simpara>\r
1035 <simpara>Everything above this line in this section isn't included from the\r
1036 <xref linkend="git-config(1)" /> documentation. The content that follows is the\r
1037 same as what's found there:</simpara>\r
1038 <variablelist>\r
1039 <varlistentry>\r
1040 <term>\r
1041 commit.cleanup\r
1042 </term>\r
1043 <listitem>\r
1044 <simpara>\r
1045         This setting overrides the default of the <emphasis>--cleanup</emphasis> option in\r
1046         <emphasis>git commit</emphasis>. See <xref linkend="git-commit(1)" /> for details. Changing the\r
1047         default can be useful when you always want to keep lines that begin\r
1048         with the comment character <emphasis>#</emphasis> in your log message, in which case you\r
1049         would do <emphasis>git config commit.cleanup whitespace</emphasis> (note that you will\r
1050         have to remove the help lines that begin with <emphasis>#</emphasis> in the commit log\r
1051         template yourself, if you do this).\r
1052 </simpara>\r
1053 </listitem>\r
1054 </varlistentry>\r
1055 <varlistentry>\r
1056 <term>\r
1057 commit.gpgSign\r
1058 </term>\r
1059 <listitem>\r
1060 <simpara>\r
1061         A boolean to specify whether all commits should be GPG signed.\r
1062         Use of this option when doing operations such as rebase can\r
1063         result in a large number of commits being signed. It may be\r
1064         convenient to use an agent to avoid typing your GPG passphrase\r
1065         several times.\r
1066 </simpara>\r
1067 </listitem>\r
1068 </varlistentry>\r
1069 <varlistentry>\r
1070 <term>\r
1071 commit.status\r
1072 </term>\r
1073 <listitem>\r
1074 <simpara>\r
1075         A boolean to enable/disable inclusion of status information in the\r
1076         commit message template when using an editor to prepare the commit\r
1077         message.  Defaults to true.\r
1078 </simpara>\r
1079 </listitem>\r
1080 </varlistentry>\r
1081 <varlistentry>\r
1082 <term>\r
1083 commit.template\r
1084 </term>\r
1085 <listitem>\r
1086 <simpara>\r
1087         Specify the pathname of a file to use as the template for\r
1088         new commit messages.\r
1089 </simpara>\r
1090 </listitem>\r
1091 </varlistentry>\r
1092 <varlistentry>\r
1093 <term>\r
1094 commit.verbose\r
1095 </term>\r
1096 <listitem>\r
1097 <simpara>\r
1098         A boolean or int to specify the level of verbosity with <emphasis>git commit</emphasis>.\r
1099         See <xref linkend="git-commit(1)" />.\r
1100 </simpara>\r
1101 </listitem>\r
1102 </varlistentry>\r
1103 </variablelist>\r
1104 </simplesect>\r
1105 <simplesect id="git-commit(1)__hooks">\r
1106 <title>HOOKS</title>\r
1107 <simpara>This command can run <emphasis>commit-msg</emphasis>, <emphasis>prepare-commit-msg</emphasis>, <emphasis>pre-commit</emphasis>,\r
1108 <emphasis>post-commit</emphasis> and <emphasis>post-rewrite</emphasis> hooks.  See <xref linkend="githooks(5)" /> for more\r
1109 information.</simpara>\r
1110 </simplesect>\r
1111 <simplesect id="git-commit(1)__files">\r
1112 <title>FILES</title>\r
1113 <variablelist>\r
1114 <varlistentry>\r
1115 <term>\r
1116 <emphasis>$GIT_DIR/COMMIT_EDITMSG</emphasis>\r
1117 </term>\r
1118 <listitem>\r
1119 <simpara>\r
1120         This file contains the commit message of a commit in progress.\r
1121         If <emphasis>git commit</emphasis> exits due to an error before creating a commit,\r
1122         any commit message that has been provided by the user (e.g., in\r
1123         an editor session) will be available in this file, but will be\r
1124         overwritten by the next invocation of <emphasis>git commit</emphasis>.\r
1125 </simpara>\r
1126 </listitem>\r
1127 </varlistentry>\r
1128 </variablelist>\r
1129 </simplesect>\r
1130 <simplesect id="git-commit(1)__see_also">\r
1131 <title>SEE ALSO</title>\r
1132 <simpara><xref linkend="git-add(1)" />,\r
1133 <xref linkend="git-rm(1)" />,\r
1134 <xref linkend="git-mv(1)" />,\r
1135 <xref linkend="git-merge(1)" />,\r
1136 <xref linkend="git-commit-tree(1)" /></simpara>\r
1137 </simplesect>\r
1138 <simplesect id="git-commit(1)__git">\r
1139 <title>GIT</title>\r
1140 <simpara>Part of the <xref linkend="git(1)" /> suite</simpara>\r
1141 </simplesect>\r
1142 </sect2>\r