You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1848 lines
54 KiB
HTML
1848 lines
54 KiB
HTML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
|
|
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
|
|
<meta name="generator" content="AsciiDoc 9.1.0" />
|
|
<title>git-commit(1)</title>
|
|
<style type="text/css">
|
|
/* Shared CSS for AsciiDoc xhtml11 and html5 backends */
|
|
|
|
/* Default font. */
|
|
body {
|
|
font-family: Georgia,serif;
|
|
}
|
|
|
|
/* Title font. */
|
|
h1, h2, h3, h4, h5, h6,
|
|
div.title, caption.title,
|
|
thead, p.table.header,
|
|
#toctitle,
|
|
#author, #revnumber, #revdate, #revremark,
|
|
#footer {
|
|
font-family: Arial,Helvetica,sans-serif;
|
|
}
|
|
|
|
body {
|
|
margin: 1em 5% 1em 5%;
|
|
}
|
|
|
|
a {
|
|
color: blue;
|
|
text-decoration: underline;
|
|
}
|
|
a:visited {
|
|
color: fuchsia;
|
|
}
|
|
|
|
em {
|
|
font-style: italic;
|
|
color: navy;
|
|
}
|
|
|
|
strong {
|
|
font-weight: bold;
|
|
color: #083194;
|
|
}
|
|
|
|
h1, h2, h3, h4, h5, h6 {
|
|
color: #527bbd;
|
|
margin-top: 1.2em;
|
|
margin-bottom: 0.5em;
|
|
line-height: 1.3;
|
|
}
|
|
|
|
h1, h2, h3 {
|
|
border-bottom: 2px solid silver;
|
|
}
|
|
h2 {
|
|
padding-top: 0.5em;
|
|
}
|
|
h3 {
|
|
float: left;
|
|
}
|
|
h3 + * {
|
|
clear: left;
|
|
}
|
|
h5 {
|
|
font-size: 1.0em;
|
|
}
|
|
|
|
div.sectionbody {
|
|
margin-left: 0;
|
|
}
|
|
|
|
hr {
|
|
border: 1px solid silver;
|
|
}
|
|
|
|
p {
|
|
margin-top: 0.5em;
|
|
margin-bottom: 0.5em;
|
|
}
|
|
|
|
ul, ol, li > p {
|
|
margin-top: 0;
|
|
}
|
|
ul > li { color: #aaa; }
|
|
ul > li > * { color: black; }
|
|
|
|
.monospaced, code, pre {
|
|
font-family: "Courier New", Courier, monospace;
|
|
font-size: inherit;
|
|
color: navy;
|
|
padding: 0;
|
|
margin: 0;
|
|
}
|
|
pre {
|
|
white-space: pre-wrap;
|
|
}
|
|
|
|
#author {
|
|
color: #527bbd;
|
|
font-weight: bold;
|
|
font-size: 1.1em;
|
|
}
|
|
#email {
|
|
}
|
|
#revnumber, #revdate, #revremark {
|
|
}
|
|
|
|
#footer {
|
|
font-size: small;
|
|
border-top: 2px solid silver;
|
|
padding-top: 0.5em;
|
|
margin-top: 4.0em;
|
|
}
|
|
#footer-text {
|
|
float: left;
|
|
padding-bottom: 0.5em;
|
|
}
|
|
#footer-badges {
|
|
float: right;
|
|
padding-bottom: 0.5em;
|
|
}
|
|
|
|
#preamble {
|
|
margin-top: 1.5em;
|
|
margin-bottom: 1.5em;
|
|
}
|
|
div.imageblock, div.exampleblock, div.verseblock,
|
|
div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
|
|
div.admonitionblock {
|
|
margin-top: 1.0em;
|
|
margin-bottom: 1.5em;
|
|
}
|
|
div.admonitionblock {
|
|
margin-top: 2.0em;
|
|
margin-bottom: 2.0em;
|
|
margin-right: 10%;
|
|
color: #606060;
|
|
}
|
|
|
|
div.content { /* Block element content. */
|
|
padding: 0;
|
|
}
|
|
|
|
/* Block element titles. */
|
|
div.title, caption.title {
|
|
color: #527bbd;
|
|
font-weight: bold;
|
|
text-align: left;
|
|
margin-top: 1.0em;
|
|
margin-bottom: 0.5em;
|
|
}
|
|
div.title + * {
|
|
margin-top: 0;
|
|
}
|
|
|
|
td div.title:first-child {
|
|
margin-top: 0.0em;
|
|
}
|
|
div.content div.title:first-child {
|
|
margin-top: 0.0em;
|
|
}
|
|
div.content + div.title {
|
|
margin-top: 0.0em;
|
|
}
|
|
|
|
div.sidebarblock > div.content {
|
|
background: #ffffee;
|
|
border: 1px solid #dddddd;
|
|
border-left: 4px solid #f0f0f0;
|
|
padding: 0.5em;
|
|
}
|
|
|
|
div.listingblock > div.content {
|
|
border: 1px solid #dddddd;
|
|
border-left: 5px solid #f0f0f0;
|
|
background: #f8f8f8;
|
|
padding: 0.5em;
|
|
}
|
|
|
|
div.quoteblock, div.verseblock {
|
|
padding-left: 1.0em;
|
|
margin-left: 1.0em;
|
|
margin-right: 10%;
|
|
border-left: 5px solid #f0f0f0;
|
|
color: #888;
|
|
}
|
|
|
|
div.quoteblock > div.attribution {
|
|
padding-top: 0.5em;
|
|
text-align: right;
|
|
}
|
|
|
|
div.verseblock > pre.content {
|
|
font-family: inherit;
|
|
font-size: inherit;
|
|
}
|
|
div.verseblock > div.attribution {
|
|
padding-top: 0.75em;
|
|
text-align: left;
|
|
}
|
|
/* DEPRECATED: Pre version 8.2.7 verse style literal block. */
|
|
div.verseblock + div.attribution {
|
|
text-align: left;
|
|
}
|
|
|
|
div.admonitionblock .icon {
|
|
vertical-align: top;
|
|
font-size: 1.1em;
|
|
font-weight: bold;
|
|
text-decoration: underline;
|
|
color: #527bbd;
|
|
padding-right: 0.5em;
|
|
}
|
|
div.admonitionblock td.content {
|
|
padding-left: 0.5em;
|
|
border-left: 3px solid #dddddd;
|
|
}
|
|
|
|
div.exampleblock > div.content {
|
|
border-left: 3px solid #dddddd;
|
|
padding-left: 0.5em;
|
|
}
|
|
|
|
div.imageblock div.content { padding-left: 0; }
|
|
span.image img { border-style: none; vertical-align: text-bottom; }
|
|
a.image:visited { color: white; }
|
|
|
|
dl {
|
|
margin-top: 0.8em;
|
|
margin-bottom: 0.8em;
|
|
}
|
|
dt {
|
|
margin-top: 0.5em;
|
|
margin-bottom: 0;
|
|
font-style: normal;
|
|
color: navy;
|
|
}
|
|
dd > *:first-child {
|
|
margin-top: 0.1em;
|
|
}
|
|
|
|
ul, ol {
|
|
list-style-position: outside;
|
|
}
|
|
ol.arabic {
|
|
list-style-type: decimal;
|
|
}
|
|
ol.loweralpha {
|
|
list-style-type: lower-alpha;
|
|
}
|
|
ol.upperalpha {
|
|
list-style-type: upper-alpha;
|
|
}
|
|
ol.lowerroman {
|
|
list-style-type: lower-roman;
|
|
}
|
|
ol.upperroman {
|
|
list-style-type: upper-roman;
|
|
}
|
|
|
|
div.compact ul, div.compact ol,
|
|
div.compact p, div.compact p,
|
|
div.compact div, div.compact div {
|
|
margin-top: 0.1em;
|
|
margin-bottom: 0.1em;
|
|
}
|
|
|
|
tfoot {
|
|
font-weight: bold;
|
|
}
|
|
td > div.verse {
|
|
white-space: pre;
|
|
}
|
|
|
|
div.hdlist {
|
|
margin-top: 0.8em;
|
|
margin-bottom: 0.8em;
|
|
}
|
|
div.hdlist tr {
|
|
padding-bottom: 15px;
|
|
}
|
|
dt.hdlist1.strong, td.hdlist1.strong {
|
|
font-weight: bold;
|
|
}
|
|
td.hdlist1 {
|
|
vertical-align: top;
|
|
font-style: normal;
|
|
padding-right: 0.8em;
|
|
color: navy;
|
|
}
|
|
td.hdlist2 {
|
|
vertical-align: top;
|
|
}
|
|
div.hdlist.compact tr {
|
|
margin: 0;
|
|
padding-bottom: 0;
|
|
}
|
|
|
|
.comment {
|
|
background: yellow;
|
|
}
|
|
|
|
.footnote, .footnoteref {
|
|
font-size: 0.8em;
|
|
}
|
|
|
|
span.footnote, span.footnoteref {
|
|
vertical-align: super;
|
|
}
|
|
|
|
#footnotes {
|
|
margin: 20px 0 20px 0;
|
|
padding: 7px 0 0 0;
|
|
}
|
|
|
|
#footnotes div.footnote {
|
|
margin: 0 0 5px 0;
|
|
}
|
|
|
|
#footnotes hr {
|
|
border: none;
|
|
border-top: 1px solid silver;
|
|
height: 1px;
|
|
text-align: left;
|
|
margin-left: 0;
|
|
width: 20%;
|
|
min-width: 100px;
|
|
}
|
|
|
|
div.colist td {
|
|
padding-right: 0.5em;
|
|
padding-bottom: 0.3em;
|
|
vertical-align: top;
|
|
}
|
|
div.colist td img {
|
|
margin-top: 0.3em;
|
|
}
|
|
|
|
@media print {
|
|
#footer-badges { display: none; }
|
|
}
|
|
|
|
#toc {
|
|
margin-bottom: 2.5em;
|
|
}
|
|
|
|
#toctitle {
|
|
color: #527bbd;
|
|
font-size: 1.1em;
|
|
font-weight: bold;
|
|
margin-top: 1.0em;
|
|
margin-bottom: 0.1em;
|
|
}
|
|
|
|
div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
|
|
margin-top: 0;
|
|
margin-bottom: 0;
|
|
}
|
|
div.toclevel2 {
|
|
margin-left: 2em;
|
|
font-size: 0.9em;
|
|
}
|
|
div.toclevel3 {
|
|
margin-left: 4em;
|
|
font-size: 0.9em;
|
|
}
|
|
div.toclevel4 {
|
|
margin-left: 6em;
|
|
font-size: 0.9em;
|
|
}
|
|
|
|
span.aqua { color: aqua; }
|
|
span.black { color: black; }
|
|
span.blue { color: blue; }
|
|
span.fuchsia { color: fuchsia; }
|
|
span.gray { color: gray; }
|
|
span.green { color: green; }
|
|
span.lime { color: lime; }
|
|
span.maroon { color: maroon; }
|
|
span.navy { color: navy; }
|
|
span.olive { color: olive; }
|
|
span.purple { color: purple; }
|
|
span.red { color: red; }
|
|
span.silver { color: silver; }
|
|
span.teal { color: teal; }
|
|
span.white { color: white; }
|
|
span.yellow { color: yellow; }
|
|
|
|
span.aqua-background { background: aqua; }
|
|
span.black-background { background: black; }
|
|
span.blue-background { background: blue; }
|
|
span.fuchsia-background { background: fuchsia; }
|
|
span.gray-background { background: gray; }
|
|
span.green-background { background: green; }
|
|
span.lime-background { background: lime; }
|
|
span.maroon-background { background: maroon; }
|
|
span.navy-background { background: navy; }
|
|
span.olive-background { background: olive; }
|
|
span.purple-background { background: purple; }
|
|
span.red-background { background: red; }
|
|
span.silver-background { background: silver; }
|
|
span.teal-background { background: teal; }
|
|
span.white-background { background: white; }
|
|
span.yellow-background { background: yellow; }
|
|
|
|
span.big { font-size: 2em; }
|
|
span.small { font-size: 0.6em; }
|
|
|
|
span.underline { text-decoration: underline; }
|
|
span.overline { text-decoration: overline; }
|
|
span.line-through { text-decoration: line-through; }
|
|
|
|
div.unbreakable { page-break-inside: avoid; }
|
|
|
|
|
|
/*
|
|
* xhtml11 specific
|
|
*
|
|
* */
|
|
|
|
div.tableblock {
|
|
margin-top: 1.0em;
|
|
margin-bottom: 1.5em;
|
|
}
|
|
div.tableblock > table {
|
|
border: 3px solid #527bbd;
|
|
}
|
|
thead, p.table.header {
|
|
font-weight: bold;
|
|
color: #527bbd;
|
|
}
|
|
p.table {
|
|
margin-top: 0;
|
|
}
|
|
/* Because the table frame attribute is overridden by CSS in most browsers. */
|
|
div.tableblock > table[frame="void"] {
|
|
border-style: none;
|
|
}
|
|
div.tableblock > table[frame="hsides"] {
|
|
border-left-style: none;
|
|
border-right-style: none;
|
|
}
|
|
div.tableblock > table[frame="vsides"] {
|
|
border-top-style: none;
|
|
border-bottom-style: none;
|
|
}
|
|
|
|
|
|
/*
|
|
* html5 specific
|
|
*
|
|
* */
|
|
|
|
table.tableblock {
|
|
margin-top: 1.0em;
|
|
margin-bottom: 1.5em;
|
|
}
|
|
thead, p.tableblock.header {
|
|
font-weight: bold;
|
|
color: #527bbd;
|
|
}
|
|
p.tableblock {
|
|
margin-top: 0;
|
|
}
|
|
table.tableblock {
|
|
border-width: 3px;
|
|
border-spacing: 0px;
|
|
border-style: solid;
|
|
border-color: #527bbd;
|
|
border-collapse: collapse;
|
|
}
|
|
th.tableblock, td.tableblock {
|
|
border-width: 1px;
|
|
padding: 4px;
|
|
border-style: solid;
|
|
border-color: #527bbd;
|
|
}
|
|
|
|
table.tableblock.frame-topbot {
|
|
border-left-style: hidden;
|
|
border-right-style: hidden;
|
|
}
|
|
table.tableblock.frame-sides {
|
|
border-top-style: hidden;
|
|
border-bottom-style: hidden;
|
|
}
|
|
table.tableblock.frame-none {
|
|
border-style: hidden;
|
|
}
|
|
|
|
th.tableblock.halign-left, td.tableblock.halign-left {
|
|
text-align: left;
|
|
}
|
|
th.tableblock.halign-center, td.tableblock.halign-center {
|
|
text-align: center;
|
|
}
|
|
th.tableblock.halign-right, td.tableblock.halign-right {
|
|
text-align: right;
|
|
}
|
|
|
|
th.tableblock.valign-top, td.tableblock.valign-top {
|
|
vertical-align: top;
|
|
}
|
|
th.tableblock.valign-middle, td.tableblock.valign-middle {
|
|
vertical-align: middle;
|
|
}
|
|
th.tableblock.valign-bottom, td.tableblock.valign-bottom {
|
|
vertical-align: bottom;
|
|
}
|
|
|
|
|
|
/*
|
|
* manpage specific
|
|
*
|
|
* */
|
|
|
|
body.manpage h1 {
|
|
padding-top: 0.5em;
|
|
padding-bottom: 0.5em;
|
|
border-top: 2px solid silver;
|
|
border-bottom: 2px solid silver;
|
|
}
|
|
body.manpage h2 {
|
|
border-style: none;
|
|
}
|
|
body.manpage div.sectionbody {
|
|
margin-left: 3em;
|
|
}
|
|
|
|
@media print {
|
|
body.manpage div#toc { display: none; }
|
|
}
|
|
|
|
|
|
</style>
|
|
<script type="text/javascript">
|
|
/*<![CDATA[*/
|
|
var asciidoc = { // Namespace.
|
|
|
|
/////////////////////////////////////////////////////////////////////
|
|
// Table Of Contents generator
|
|
/////////////////////////////////////////////////////////////////////
|
|
|
|
/* Author: Mihai Bazon, September 2002
|
|
* http://students.infoiasi.ro/~mishoo
|
|
*
|
|
* Table Of Content generator
|
|
* Version: 0.4
|
|
*
|
|
* Feel free to use this script under the terms of the GNU General Public
|
|
* License, as long as you do not remove or alter this notice.
|
|
*/
|
|
|
|
/* modified by Troy D. Hanson, September 2006. License: GPL */
|
|
/* modified by Stuart Rackham, 2006, 2009. License: GPL */
|
|
|
|
// toclevels = 1..4.
|
|
toc: function (toclevels) {
|
|
|
|
function getText(el) {
|
|
var text = "";
|
|
for (var i = el.firstChild; i != null; i = i.nextSibling) {
|
|
if (i.nodeType == 3 /* Node.TEXT_NODE */) // IE doesn't speak constants.
|
|
text += i.data;
|
|
else if (i.firstChild != null)
|
|
text += getText(i);
|
|
}
|
|
return text;
|
|
}
|
|
|
|
function TocEntry(el, text, toclevel) {
|
|
this.element = el;
|
|
this.text = text;
|
|
this.toclevel = toclevel;
|
|
}
|
|
|
|
function tocEntries(el, toclevels) {
|
|
var result = new Array;
|
|
var re = new RegExp('[hH]([1-'+(toclevels+1)+'])');
|
|
// Function that scans the DOM tree for header elements (the DOM2
|
|
// nodeIterator API would be a better technique but not supported by all
|
|
// browsers).
|
|
var iterate = function (el) {
|
|
for (var i = el.firstChild; i != null; i = i.nextSibling) {
|
|
if (i.nodeType == 1 /* Node.ELEMENT_NODE */) {
|
|
var mo = re.exec(i.tagName);
|
|
if (mo && (i.getAttribute("class") || i.getAttribute("className")) != "float") {
|
|
result[result.length] = new TocEntry(i, getText(i), mo[1]-1);
|
|
}
|
|
iterate(i);
|
|
}
|
|
}
|
|
}
|
|
iterate(el);
|
|
return result;
|
|
}
|
|
|
|
var toc = document.getElementById("toc");
|
|
if (!toc) {
|
|
return;
|
|
}
|
|
|
|
// Delete existing TOC entries in case we're reloading the TOC.
|
|
var tocEntriesToRemove = [];
|
|
var i;
|
|
for (i = 0; i < toc.childNodes.length; i++) {
|
|
var entry = toc.childNodes[i];
|
|
if (entry.nodeName.toLowerCase() == 'div'
|
|
&& entry.getAttribute("class")
|
|
&& entry.getAttribute("class").match(/^toclevel/))
|
|
tocEntriesToRemove.push(entry);
|
|
}
|
|
for (i = 0; i < tocEntriesToRemove.length; i++) {
|
|
toc.removeChild(tocEntriesToRemove[i]);
|
|
}
|
|
|
|
// Rebuild TOC entries.
|
|
var entries = tocEntries(document.getElementById("content"), toclevels);
|
|
for (var i = 0; i < entries.length; ++i) {
|
|
var entry = entries[i];
|
|
if (entry.element.id == "")
|
|
entry.element.id = "_toc_" + i;
|
|
var a = document.createElement("a");
|
|
a.href = "#" + entry.element.id;
|
|
a.appendChild(document.createTextNode(entry.text));
|
|
var div = document.createElement("div");
|
|
div.appendChild(a);
|
|
div.className = "toclevel" + entry.toclevel;
|
|
toc.appendChild(div);
|
|
}
|
|
if (entries.length == 0)
|
|
toc.parentNode.removeChild(toc);
|
|
},
|
|
|
|
|
|
/////////////////////////////////////////////////////////////////////
|
|
// Footnotes generator
|
|
/////////////////////////////////////////////////////////////////////
|
|
|
|
/* Based on footnote generation code from:
|
|
* http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
|
|
*/
|
|
|
|
footnotes: function () {
|
|
// Delete existing footnote entries in case we're reloading the footnodes.
|
|
var i;
|
|
var noteholder = document.getElementById("footnotes");
|
|
if (!noteholder) {
|
|
return;
|
|
}
|
|
var entriesToRemove = [];
|
|
for (i = 0; i < noteholder.childNodes.length; i++) {
|
|
var entry = noteholder.childNodes[i];
|
|
if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote")
|
|
entriesToRemove.push(entry);
|
|
}
|
|
for (i = 0; i < entriesToRemove.length; i++) {
|
|
noteholder.removeChild(entriesToRemove[i]);
|
|
}
|
|
|
|
// Rebuild footnote entries.
|
|
var cont = document.getElementById("content");
|
|
var spans = cont.getElementsByTagName("span");
|
|
var refs = {};
|
|
var n = 0;
|
|
for (i=0; i<spans.length; i++) {
|
|
if (spans[i].className == "footnote") {
|
|
n++;
|
|
var note = spans[i].getAttribute("data-note");
|
|
if (!note) {
|
|
// Use [\s\S] in place of . so multi-line matches work.
|
|
// Because JavaScript has no s (dotall) regex flag.
|
|
note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[1];
|
|
spans[i].innerHTML =
|
|
"[<a id='_footnoteref_" + n + "' href='#_footnote_" + n +
|
|
"' title='View footnote' class='footnote'>" + n + "</a>]";
|
|
spans[i].setAttribute("data-note", note);
|
|
}
|
|
noteholder.innerHTML +=
|
|
"<div class='footnote' id='_footnote_" + n + "'>" +
|
|
"<a href='#_footnoteref_" + n + "' title='Return to text'>" +
|
|
n + "</a>. " + note + "</div>";
|
|
var id =spans[i].getAttribute("id");
|
|
if (id != null) refs["#"+id] = n;
|
|
}
|
|
}
|
|
if (n == 0)
|
|
noteholder.parentNode.removeChild(noteholder);
|
|
else {
|
|
// Process footnoterefs.
|
|
for (i=0; i<spans.length; i++) {
|
|
if (spans[i].className == "footnoteref") {
|
|
var href = spans[i].getElementsByTagName("a")[0].getAttribute("href");
|
|
href = href.match(/#.*/)[0]; // Because IE return full URL.
|
|
n = refs[href];
|
|
spans[i].innerHTML =
|
|
"[<a href='#_footnote_" + n +
|
|
"' title='View footnote' class='footnote'>" + n + "</a>]";
|
|
}
|
|
}
|
|
}
|
|
},
|
|
|
|
install: function(toclevels) {
|
|
var timerId;
|
|
|
|
function reinstall() {
|
|
asciidoc.footnotes();
|
|
if (toclevels) {
|
|
asciidoc.toc(toclevels);
|
|
}
|
|
}
|
|
|
|
function reinstallAndRemoveTimer() {
|
|
clearInterval(timerId);
|
|
reinstall();
|
|
}
|
|
|
|
timerId = setInterval(reinstall, 500);
|
|
if (document.addEventListener)
|
|
document.addEventListener("DOMContentLoaded", reinstallAndRemoveTimer, false);
|
|
else
|
|
window.onload = reinstallAndRemoveTimer;
|
|
}
|
|
|
|
}
|
|
asciidoc.install();
|
|
/*]]>*/
|
|
</script>
|
|
</head>
|
|
<body class="manpage">
|
|
<div id="header">
|
|
<h1>
|
|
git-commit(1) Manual Page
|
|
</h1>
|
|
<h2>NAME</h2>
|
|
<div class="sectionbody">
|
|
<p>git-commit -
|
|
Record changes to the repository
|
|
</p>
|
|
</div>
|
|
</div>
|
|
<div id="content">
|
|
<div class="sect1">
|
|
<h2 id="_synopsis">SYNOPSIS</h2>
|
|
<div class="sectionbody">
|
|
<div class="verseblock">
|
|
<pre class="content"><em>git commit</em> [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
|
|
[--dry-run] [(-c | -C | --squash) <commit> | --fixup [(amend|reword):]<commit>)]
|
|
[-F <file> | -m <msg>] [--reset-author] [--allow-empty]
|
|
[--allow-empty-message] [--no-verify] [-e] [--author=<author>]
|
|
[--date=<date>] [--cleanup=<mode>] [--[no-]status]
|
|
[-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]]
|
|
[(--trailer <token>[(=|:)<value>])…] [-S[<keyid>]]
|
|
[--] [<pathspec>…]</pre>
|
|
<div class="attribution">
|
|
</div></div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_description">DESCRIPTION</h2>
|
|
<div class="sectionbody">
|
|
<div class="paragraph"><p>Create a new commit containing the current contents of the index and
|
|
the given log message describing the changes. The new commit is a
|
|
direct child of HEAD, usually the tip of the current branch, and the
|
|
branch is updated to point to it (unless no branch is associated with
|
|
the working tree, in which case HEAD is "detached" as described in
|
|
<a href="git-checkout.html">git-checkout(1)</a>).</p></div>
|
|
<div class="paragraph"><p>The content to be committed can be specified in several ways:</p></div>
|
|
<div class="olist arabic"><ol class="arabic">
|
|
<li>
|
|
<p>
|
|
by using <a href="git-add.html">git-add(1)</a> to incrementally "add" changes to the
|
|
index before using the <em>commit</em> command (Note: even modified files
|
|
must be "added");
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
by using <a href="git-rm.html">git-rm(1)</a> to remove files from the working tree
|
|
and the index, again before using the <em>commit</em> command;
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
by listing files as arguments to the <em>commit</em> command
|
|
(without --interactive or --patch switch), in which
|
|
case the commit will ignore changes staged in the index, and instead
|
|
record the current content of the listed files (which must already
|
|
be known to Git);
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
by using the -a switch with the <em>commit</em> command to automatically
|
|
"add" changes from all known files (i.e. all files that are already
|
|
listed in the index) and to automatically "rm" files in the index
|
|
that have been removed from the working tree, and then perform the
|
|
actual commit;
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
by using the --interactive or --patch switches with the <em>commit</em> command
|
|
to decide one by one which files or hunks should be part of the commit
|
|
in addition to contents in the index,
|
|
before finalizing the operation. See the “Interactive Mode” section of
|
|
<a href="git-add.html">git-add(1)</a> to learn how to operate these modes.
|
|
</p>
|
|
</li>
|
|
</ol></div>
|
|
<div class="paragraph"><p>The <code>--dry-run</code> option can be used to obtain a
|
|
summary of what is included by any of the above for the next
|
|
commit by giving the same set of parameters (options and paths).</p></div>
|
|
<div class="paragraph"><p>If you make a commit and then find a mistake immediately after
|
|
that, you can recover from it with <em>git reset</em>.</p></div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_options">OPTIONS</h2>
|
|
<div class="sectionbody">
|
|
<div class="dlist"><dl>
|
|
<dt class="hdlist1">
|
|
-a
|
|
</dt>
|
|
<dt class="hdlist1">
|
|
--all
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Tell the command to automatically stage files that have
|
|
been modified and deleted, but new files you have not
|
|
told Git about are not affected.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
-p
|
|
</dt>
|
|
<dt class="hdlist1">
|
|
--patch
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Use the interactive patch selection interface to choose
|
|
which changes to commit. See <a href="git-add.html">git-add(1)</a> for
|
|
details.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
-C <commit>
|
|
</dt>
|
|
<dt class="hdlist1">
|
|
--reuse-message=<commit>
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Take an existing commit object, and reuse the log message
|
|
and the authorship information (including the timestamp)
|
|
when creating the commit.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
-c <commit>
|
|
</dt>
|
|
<dt class="hdlist1">
|
|
--reedit-message=<commit>
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Like <em>-C</em>, but with <code>-c</code> the editor is invoked, so that
|
|
the user can further edit the commit message.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--fixup=[(amend|reword):]<commit>
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Create a new commit which "fixes up" <code><commit></code> when applied with
|
|
<code>git rebase --autosquash</code>. Plain <code>--fixup=<commit></code> creates a
|
|
"fixup!" commit which changes the content of <code><commit></code> but leaves
|
|
its log message untouched. <code>--fixup=amend:<commit></code> is similar but
|
|
creates an "amend!" commit which also replaces the log message of
|
|
<code><commit></code> with the log message of the "amend!" commit.
|
|
<code>--fixup=reword:<commit></code> creates an "amend!" commit which
|
|
replaces the log message of <code><commit></code> with its own log message
|
|
but makes no changes to the content of <code><commit></code>.
|
|
</p>
|
|
<div class="paragraph"><p>The commit created by plain <code>--fixup=<commit></code> has a subject
|
|
composed of "fixup!" followed by the subject line from <commit>,
|
|
and is recognized specially by <code>git rebase --autosquash</code>. The <code>-m</code>
|
|
option may be used to supplement the log message of the created
|
|
commit, but the additional commentary will be thrown away once the
|
|
"fixup!" commit is squashed into <code><commit></code> by
|
|
<code>git rebase --autosquash</code>.</p></div>
|
|
<div class="paragraph"><p>The commit created by <code>--fixup=amend:<commit></code> is similar but its
|
|
subject is instead prefixed with "amend!". The log message of
|
|
<commit> is copied into the log message of the "amend!" commit and
|
|
opened in an editor so it can be refined. When <code>git rebase
|
|
--autosquash</code> squashes the "amend!" commit into <code><commit></code>, the
|
|
log message of <code><commit></code> is replaced by the refined log message
|
|
from the "amend!" commit. It is an error for the "amend!" commit’s
|
|
log message to be empty unless <code>--allow-empty-message</code> is
|
|
specified.</p></div>
|
|
<div class="paragraph"><p><code>--fixup=reword:<commit></code> is shorthand for <code>--fixup=amend:<commit>
|
|
--only</code>. It creates an "amend!" commit with only a log message
|
|
(ignoring any changes staged in the index). When squashed by <code>git
|
|
rebase --autosquash</code>, it replaces the log message of <code><commit></code>
|
|
without making any other changes.</p></div>
|
|
<div class="paragraph"><p>Neither "fixup!" nor "amend!" commits change authorship of
|
|
<code><commit></code> when applied by <code>git rebase --autosquash</code>.
|
|
See <a href="git-rebase.html">git-rebase(1)</a> for details.</p></div>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--squash=<commit>
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Construct a commit message for use with <code>rebase --autosquash</code>.
|
|
The commit message subject line is taken from the specified
|
|
commit with a prefix of "squash! ". Can be used with additional
|
|
commit message options (<code>-m</code>/<code>-c</code>/<code>-C</code>/<code>-F</code>). See
|
|
<a href="git-rebase.html">git-rebase(1)</a> for details.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--reset-author
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
When used with -C/-c/--amend options, or when committing after a
|
|
conflicting cherry-pick, declare that the authorship of the
|
|
resulting commit now belongs to the committer. This also renews
|
|
the author timestamp.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--short
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
When doing a dry-run, give the output in the short-format. See
|
|
<a href="git-status.html">git-status(1)</a> for details. Implies <code>--dry-run</code>.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--branch
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Show the branch and tracking info even in short-format.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--porcelain
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
When doing a dry-run, give the output in a porcelain-ready
|
|
format. See <a href="git-status.html">git-status(1)</a> for details. Implies
|
|
<code>--dry-run</code>.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--long
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
When doing a dry-run, give the output in the long-format.
|
|
Implies <code>--dry-run</code>.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
-z
|
|
</dt>
|
|
<dt class="hdlist1">
|
|
--null
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
When showing <code>short</code> or <code>porcelain</code> status output, print the
|
|
filename verbatim and terminate the entries with NUL, instead of LF.
|
|
If no format is given, implies the <code>--porcelain</code> output format.
|
|
Without the <code>-z</code> option, filenames with "unusual" characters are
|
|
quoted as explained for the configuration variable <code>core.quotePath</code>
|
|
(see <a href="git-config.html">git-config(1)</a>).
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
-F <file>
|
|
</dt>
|
|
<dt class="hdlist1">
|
|
--file=<file>
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Take the commit message from the given file. Use <em>-</em> to
|
|
read the message from the standard input.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--author=<author>
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Override the commit author. Specify an explicit author using the
|
|
standard <code>A U Thor <author@example.com></code> format. Otherwise <author>
|
|
is assumed to be a pattern and is used to search for an existing
|
|
commit by that author (i.e. rev-list --all -i --author=<author>);
|
|
the commit author is then copied from the first such commit found.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--date=<date>
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Override the author date used in the commit.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
-m <msg>
|
|
</dt>
|
|
<dt class="hdlist1">
|
|
--message=<msg>
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Use the given <msg> as the commit message.
|
|
If multiple <code>-m</code> options are given, their values are
|
|
concatenated as separate paragraphs.
|
|
</p>
|
|
<div class="paragraph"><p>The <code>-m</code> option is mutually exclusive with <code>-c</code>, <code>-C</code>, and <code>-F</code>.</p></div>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
-t <file>
|
|
</dt>
|
|
<dt class="hdlist1">
|
|
--template=<file>
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
When editing the commit message, start the editor with the
|
|
contents in the given file. The <code>commit.template</code> configuration
|
|
variable is often used to give this option implicitly to the
|
|
command. This mechanism can be used by projects that want to
|
|
guide participants with some hints on what to write in the message
|
|
in what order. If the user exits the editor without editing the
|
|
message, the commit is aborted. This has no effect when a message
|
|
is given by other means, e.g. with the <code>-m</code> or <code>-F</code> options.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
-s
|
|
</dt>
|
|
<dt class="hdlist1">
|
|
--signoff
|
|
</dt>
|
|
<dt class="hdlist1">
|
|
--no-signoff
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Add a <code>Signed-off-by</code> trailer by the committer at the end of the commit
|
|
log message. The meaning of a signoff depends on the project
|
|
to which you’re committing. For example, it may certify that
|
|
the committer has the rights to submit the work under the
|
|
project’s license or agrees to some contributor representation,
|
|
such as a Developer Certificate of Origin.
|
|
(See <a href="http://developercertificate.org">http://developercertificate.org</a> for the one used by the
|
|
Linux kernel and Git projects.) Consult the documentation or
|
|
leadership of the project to which you’re contributing to
|
|
understand how the signoffs are used in that project.
|
|
</p>
|
|
<div class="paragraph"><p>The --no-signoff option can be used to countermand an earlier --signoff
|
|
option on the command line.</p></div>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--trailer <token>[(=|:)<value>]
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Specify a (<token>, <value>) pair that should be applied as a
|
|
trailer. (e.g. <code>git commit --trailer "Signed-off-by:C O Mitter \
|
|
<committer@example.com>" --trailer "Helped-by:C O Mitter \
|
|
<committer@example.com>"</code> will add the "Signed-off-by" trailer
|
|
and the "Helped-by" trailer to the commit message.)
|
|
The <code>trailer.*</code> configuration variables
|
|
(<a href="git-interpret-trailers.html">git-interpret-trailers(1)</a>) can be used to define if
|
|
a duplicated trailer is omitted, where in the run of trailers
|
|
each trailer would appear, and other details.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
-n
|
|
</dt>
|
|
<dt class="hdlist1">
|
|
--[no-]verify
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
By default, the pre-commit and commit-msg hooks are run.
|
|
When any of <code>--no-verify</code> or <code>-n</code> is given, these are bypassed.
|
|
See also <a href="githooks.html">githooks(5)</a>.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--allow-empty
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Usually recording a commit that has the exact same tree as its
|
|
sole parent commit is a mistake, and the command prevents you
|
|
from making such a commit. This option bypasses the safety, and
|
|
is primarily for use by foreign SCM interface scripts.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--allow-empty-message
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Like --allow-empty this command is primarily for use by foreign
|
|
SCM interface scripts. It allows you to create a commit with an
|
|
empty commit message without using plumbing commands like
|
|
<a href="git-commit-tree.html">git-commit-tree(1)</a>.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--cleanup=<mode>
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
This option determines how the supplied commit message should be
|
|
cleaned up before committing. The <em><mode></em> can be <code>strip</code>,
|
|
<code>whitespace</code>, <code>verbatim</code>, <code>scissors</code> or <code>default</code>.
|
|
</p>
|
|
<div class="openblock">
|
|
<div class="content">
|
|
<div class="dlist"><dl>
|
|
<dt class="hdlist1">
|
|
strip
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Strip leading and trailing empty lines, trailing whitespace,
|
|
commentary and collapse consecutive empty lines.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
whitespace
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Same as <code>strip</code> except #commentary is not removed.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
verbatim
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Do not change the message at all.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
scissors
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Same as <code>whitespace</code> except that everything from (and including)
|
|
the line found below is truncated, if the message is to be edited.
|
|
"<code>#</code>" can be customized with core.commentChar.
|
|
</p>
|
|
<div class="literalblock">
|
|
<div class="content">
|
|
<pre><code># ------------------------ >8 ------------------------</code></pre>
|
|
</div></div>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
default
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Same as <code>strip</code> if the message is to be edited.
|
|
Otherwise <code>whitespace</code>.
|
|
</p>
|
|
</dd>
|
|
</dl></div>
|
|
</div></div>
|
|
<div class="paragraph"><p>The default can be changed by the <code>commit.cleanup</code> configuration
|
|
variable (see <a href="git-config.html">git-config(1)</a>).</p></div>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
-e
|
|
</dt>
|
|
<dt class="hdlist1">
|
|
--edit
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
The message taken from file with <code>-F</code>, command line with
|
|
<code>-m</code>, and from commit object with <code>-C</code> are usually used as
|
|
the commit log message unmodified. This option lets you
|
|
further edit the message taken from these sources.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--no-edit
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Use the selected commit message without launching an editor.
|
|
For example, <code>git commit --amend --no-edit</code> amends a commit
|
|
without changing its commit message.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--amend
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Replace the tip of the current branch by creating a new
|
|
commit. The recorded tree is prepared as usual (including
|
|
the effect of the <code>-i</code> and <code>-o</code> options and explicit
|
|
pathspec), and the message from the original commit is used
|
|
as the starting point, instead of an empty message, when no
|
|
other message is specified from the command line via options
|
|
such as <code>-m</code>, <code>-F</code>, <code>-c</code>, etc. The new commit has the same
|
|
parents and author as the current one (the <code>--reset-author</code>
|
|
option can countermand this).
|
|
</p>
|
|
<div class="openblock">
|
|
<div class="content">
|
|
<div class="paragraph"><p>It is a rough equivalent for:</p></div>
|
|
<div class="listingblock">
|
|
<div class="content">
|
|
<pre><code> $ git reset --soft HEAD^
|
|
$ ... do something else to come up with the right tree ...
|
|
$ git commit -c ORIG_HEAD</code></pre>
|
|
</div></div>
|
|
<div class="paragraph"><p>but can be used to amend a merge commit.</p></div>
|
|
</div></div>
|
|
<div class="paragraph"><p>You should understand the implications of rewriting history if you
|
|
amend a commit that has already been published. (See the "RECOVERING
|
|
FROM UPSTREAM REBASE" section in <a href="git-rebase.html">git-rebase(1)</a>.)</p></div>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--no-post-rewrite
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Bypass the post-rewrite hook.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
-i
|
|
</dt>
|
|
<dt class="hdlist1">
|
|
--include
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Before making a commit out of staged contents so far,
|
|
stage the contents of paths given on the command line
|
|
as well. This is usually not what you want unless you
|
|
are concluding a conflicted merge.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
-o
|
|
</dt>
|
|
<dt class="hdlist1">
|
|
--only
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Make a commit by taking the updated working tree contents
|
|
of the paths specified on the
|
|
command line, disregarding any contents that have been
|
|
staged for other paths. This is the default mode of operation of
|
|
<em>git commit</em> if any paths are given on the command line,
|
|
in which case this option can be omitted.
|
|
If this option is specified together with <code>--amend</code>, then
|
|
no paths need to be specified, which can be used to amend
|
|
the last commit without committing changes that have
|
|
already been staged. If used together with <code>--allow-empty</code>
|
|
paths are also not required, and an empty commit will be created.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--pathspec-from-file=<file>
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Pathspec is passed in <code><file></code> instead of commandline args. If
|
|
<code><file></code> is exactly <code>-</code> then standard input is used. Pathspec
|
|
elements are separated by LF or CR/LF. Pathspec elements can be
|
|
quoted as explained for the configuration variable <code>core.quotePath</code>
|
|
(see <a href="git-config.html">git-config(1)</a>). See also <code>--pathspec-file-nul</code> and
|
|
global <code>--literal-pathspecs</code>.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--pathspec-file-nul
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Only meaningful with <code>--pathspec-from-file</code>. Pathspec elements are
|
|
separated with NUL character and all other characters are taken
|
|
literally (including newlines and quotes).
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
-u[<mode>]
|
|
</dt>
|
|
<dt class="hdlist1">
|
|
--untracked-files[=<mode>]
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Show untracked files.
|
|
</p>
|
|
<div class="openblock">
|
|
<div class="content">
|
|
<div class="paragraph"><p>The mode parameter is optional (defaults to <em>all</em>), and is used to
|
|
specify the handling of untracked files; when -u is not used, the
|
|
default is <em>normal</em>, i.e. show untracked files and directories.</p></div>
|
|
<div class="paragraph"><p>The possible options are:</p></div>
|
|
<div class="ulist"><ul>
|
|
<li>
|
|
<p>
|
|
<em>no</em> - Show no untracked files
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<em>normal</em> - Shows untracked files and directories
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<em>all</em> - Also shows individual files in untracked directories.
|
|
</p>
|
|
</li>
|
|
</ul></div>
|
|
<div class="paragraph"><p>The default can be changed using the status.showUntrackedFiles
|
|
configuration variable documented in <a href="git-config.html">git-config(1)</a>.</p></div>
|
|
</div></div>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
-v
|
|
</dt>
|
|
<dt class="hdlist1">
|
|
--verbose
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Show unified diff between the HEAD commit and what
|
|
would be committed at the bottom of the commit message
|
|
template to help the user describe the commit by reminding
|
|
what changes the commit has.
|
|
Note that this diff output doesn’t have its
|
|
lines prefixed with <em>#</em>. This diff will not be a part
|
|
of the commit message. See the <code>commit.verbose</code> configuration
|
|
variable in <a href="git-config.html">git-config(1)</a>.
|
|
</p>
|
|
<div class="paragraph"><p>If specified twice, show in addition the unified diff between
|
|
what would be committed and the worktree files, i.e. the unstaged
|
|
changes to tracked files.</p></div>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
-q
|
|
</dt>
|
|
<dt class="hdlist1">
|
|
--quiet
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Suppress commit summary message.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--dry-run
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Do not create a commit, but show a list of paths that are
|
|
to be committed, paths with local changes that will be left
|
|
uncommitted and paths that are untracked.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--status
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Include the output of <a href="git-status.html">git-status(1)</a> in the commit
|
|
message template when using an editor to prepare the commit
|
|
message. Defaults to on, but can be used to override
|
|
configuration variable commit.status.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--no-status
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Do not include the output of <a href="git-status.html">git-status(1)</a> in the
|
|
commit message template when using an editor to prepare the
|
|
default commit message.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
-S[<keyid>]
|
|
</dt>
|
|
<dt class="hdlist1">
|
|
--gpg-sign[=<keyid>]
|
|
</dt>
|
|
<dt class="hdlist1">
|
|
--no-gpg-sign
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
GPG-sign commits. The <code>keyid</code> argument is optional and
|
|
defaults to the committer identity; if specified, it must be
|
|
stuck to the option without a space. <code>--no-gpg-sign</code> is useful to
|
|
countermand both <code>commit.gpgSign</code> configuration variable, and
|
|
earlier <code>--gpg-sign</code>.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
--
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Do not interpret any more arguments as options.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
<pathspec>…
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
When pathspec is given on the command line, commit the contents of
|
|
the files that match the pathspec without recording the changes
|
|
already added to the index. The contents of these files are also
|
|
staged for the next commit on top of what have been staged before.
|
|
</p>
|
|
<div class="paragraph"><p>For more details, see the <em>pathspec</em> entry in <a href="gitglossary.html">gitglossary(7)</a>.</p></div>
|
|
</dd>
|
|
</dl></div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_examples">EXAMPLES</h2>
|
|
<div class="sectionbody">
|
|
<div class="paragraph"><p>When recording your own work, the contents of modified files in
|
|
your working tree are temporarily stored to a staging area
|
|
called the "index" with <em>git add</em>. A file can be
|
|
reverted back, only in the index but not in the working tree,
|
|
to that of the last commit with <code>git restore --staged <file></code>,
|
|
which effectively reverts <em>git add</em> and prevents the changes to
|
|
this file from participating in the next commit. After building
|
|
the state to be committed incrementally with these commands,
|
|
<code>git commit</code> (without any pathname parameter) is used to record what
|
|
has been staged so far. This is the most basic form of the
|
|
command. An example:</p></div>
|
|
<div class="listingblock">
|
|
<div class="content">
|
|
<pre><code>$ edit hello.c
|
|
$ git rm goodbye.c
|
|
$ git add hello.c
|
|
$ git commit</code></pre>
|
|
</div></div>
|
|
<div class="paragraph"><p>Instead of staging files after each individual change, you can
|
|
tell <code>git commit</code> to notice the changes to the files whose
|
|
contents are tracked in
|
|
your working tree and do corresponding <code>git add</code> and <code>git rm</code>
|
|
for you. That is, this example does the same as the earlier
|
|
example if there is no other change in your working tree:</p></div>
|
|
<div class="listingblock">
|
|
<div class="content">
|
|
<pre><code>$ edit hello.c
|
|
$ rm goodbye.c
|
|
$ git commit -a</code></pre>
|
|
</div></div>
|
|
<div class="paragraph"><p>The command <code>git commit -a</code> first looks at your working tree,
|
|
notices that you have modified hello.c and removed goodbye.c,
|
|
and performs necessary <code>git add</code> and <code>git rm</code> for you.</p></div>
|
|
<div class="paragraph"><p>After staging changes to many files, you can alter the order the
|
|
changes are recorded in, by giving pathnames to <code>git commit</code>.
|
|
When pathnames are given, the command makes a commit that
|
|
only records the changes made to the named paths:</p></div>
|
|
<div class="listingblock">
|
|
<div class="content">
|
|
<pre><code>$ edit hello.c hello.h
|
|
$ git add hello.c hello.h
|
|
$ edit Makefile
|
|
$ git commit Makefile</code></pre>
|
|
</div></div>
|
|
<div class="paragraph"><p>This makes a commit that records the modification to <code>Makefile</code>.
|
|
The changes staged for <code>hello.c</code> and <code>hello.h</code> are not included
|
|
in the resulting commit. However, their changes are not lost — they are still staged and merely held back. After the above
|
|
sequence, if you do:</p></div>
|
|
<div class="listingblock">
|
|
<div class="content">
|
|
<pre><code>$ git commit</code></pre>
|
|
</div></div>
|
|
<div class="paragraph"><p>this second commit would record the changes to <code>hello.c</code> and
|
|
<code>hello.h</code> as expected.</p></div>
|
|
<div class="paragraph"><p>After a merge (initiated by <em>git merge</em> or <em>git pull</em>) stops
|
|
because of conflicts, cleanly merged
|
|
paths are already staged to be committed for you, and paths that
|
|
conflicted are left in unmerged state. You would have to first
|
|
check which paths are conflicting with <em>git status</em>
|
|
and after fixing them manually in your working tree, you would
|
|
stage the result as usual with <em>git add</em>:</p></div>
|
|
<div class="listingblock">
|
|
<div class="content">
|
|
<pre><code>$ git status | grep unmerged
|
|
unmerged: hello.c
|
|
$ edit hello.c
|
|
$ git add hello.c</code></pre>
|
|
</div></div>
|
|
<div class="paragraph"><p>After resolving conflicts and staging the result, <code>git ls-files -u</code>
|
|
would stop mentioning the conflicted path. When you are done,
|
|
run <code>git commit</code> to finally record the merge:</p></div>
|
|
<div class="listingblock">
|
|
<div class="content">
|
|
<pre><code>$ git commit</code></pre>
|
|
</div></div>
|
|
<div class="paragraph"><p>As with the case to record your own changes, you can use <code>-a</code>
|
|
option to save typing. One difference is that during a merge
|
|
resolution, you cannot use <code>git commit</code> with pathnames to
|
|
alter the order the changes are committed, because the merge
|
|
should be recorded as a single commit. In fact, the command
|
|
refuses to run when given pathnames (but see <code>-i</code> option).</p></div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_commit_information">COMMIT INFORMATION</h2>
|
|
<div class="sectionbody">
|
|
<div class="paragraph"><p>Author and committer information is taken from the following environment
|
|
variables, if set:</p></div>
|
|
<div class="literalblock">
|
|
<div class="content">
|
|
<pre><code>GIT_AUTHOR_NAME
|
|
GIT_AUTHOR_EMAIL
|
|
GIT_AUTHOR_DATE
|
|
GIT_COMMITTER_NAME
|
|
GIT_COMMITTER_EMAIL
|
|
GIT_COMMITTER_DATE</code></pre>
|
|
</div></div>
|
|
<div class="paragraph"><p>(nb "<", ">" and "\n"s are stripped)</p></div>
|
|
<div class="paragraph"><p>The author and committer names are by convention some form of a personal name
|
|
(that is, the name by which other humans refer to you), although Git does not
|
|
enforce or require any particular form. Arbitrary Unicode may be used, subject
|
|
to the constraints listed above. This name has no effect on authentication; for
|
|
that, see the <code>credential.username</code> variable in <a href="git-config.html">git-config(1)</a>.</p></div>
|
|
<div class="paragraph"><p>In case (some of) these environment variables are not set, the information
|
|
is taken from the configuration items <code>user.name</code> and <code>user.email</code>, or, if not
|
|
present, the environment variable EMAIL, or, if that is not set,
|
|
system user name and the hostname used for outgoing mail (taken
|
|
from <code>/etc/mailname</code> and falling back to the fully qualified hostname when
|
|
that file does not exist).</p></div>
|
|
<div class="paragraph"><p>The <code>author.name</code> and <code>committer.name</code> and their corresponding email options
|
|
override <code>user.name</code> and <code>user.email</code> if set and are overridden themselves by
|
|
the environment variables.</p></div>
|
|
<div class="paragraph"><p>The typical usage is to set just the <code>user.name</code> and <code>user.email</code> variables;
|
|
the other options are provided for more complex use cases.</p></div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_date_formats">DATE FORMATS</h2>
|
|
<div class="sectionbody">
|
|
<div class="paragraph"><p>The <code>GIT_AUTHOR_DATE</code> and <code>GIT_COMMITTER_DATE</code> environment variables
|
|
support the following date formats:</p></div>
|
|
<div class="dlist"><dl>
|
|
<dt class="hdlist1">
|
|
Git internal format
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
It is <code><unix-timestamp> <time-zone-offset></code>, where
|
|
<code><unix-timestamp></code> is the number of seconds since the UNIX epoch.
|
|
<code><time-zone-offset></code> is a positive or negative offset from UTC.
|
|
For example CET (which is 1 hour ahead of UTC) is <code>+0100</code>.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
RFC 2822
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
The standard email format as described by RFC 2822, for example
|
|
<code>Thu, 07 Apr 2005 22:13:13 +0200</code>.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
ISO 8601
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Time and date specified by the ISO 8601 standard, for example
|
|
<code>2005-04-07T22:13:13</code>. The parser accepts a space instead of the
|
|
<code>T</code> character as well. Fractional parts of a second will be ignored,
|
|
for example <code>2005-04-07T22:13:13.019</code> will be treated as
|
|
<code>2005-04-07T22:13:13</code>.
|
|
</p>
|
|
<div class="admonitionblock">
|
|
<table><tr>
|
|
<td class="icon">
|
|
<div class="title">Note</div>
|
|
</td>
|
|
<td class="content">In addition, the date part is accepted in the following formats:
|
|
<code>YYYY.MM.DD</code>, <code>MM/DD/YYYY</code> and <code>DD.MM.YYYY</code>.</td>
|
|
</tr></table>
|
|
</div>
|
|
</dd>
|
|
</dl></div>
|
|
<div class="paragraph"><p>In addition to recognizing all date formats above, the <code>--date</code> option
|
|
will also try to make sense of other, more human-centric date formats,
|
|
such as relative dates like "yesterday" or "last Friday at noon".</p></div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_discussion">DISCUSSION</h2>
|
|
<div class="sectionbody">
|
|
<div class="paragraph"><p>Though not required, it’s a good idea to begin the commit message
|
|
with a single short (less than 50 character) line summarizing the
|
|
change, followed by a blank line and then a more thorough description.
|
|
The text up to the first blank line in a commit message is treated
|
|
as the commit title, and that title is used throughout Git.
|
|
For example, <a href="git-format-patch.html">git-format-patch(1)</a> turns a commit into email, and it uses
|
|
the title on the Subject line and the rest of the commit in the body.</p></div>
|
|
<div class="paragraph"><p>Git is to some extent character encoding agnostic.</p></div>
|
|
<div class="ulist"><ul>
|
|
<li>
|
|
<p>
|
|
The contents of the blob objects are uninterpreted sequences
|
|
of bytes. There is no encoding translation at the core
|
|
level.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Path names are encoded in UTF-8 normalization form C. This
|
|
applies to tree objects, the index file, ref names, as well as
|
|
path names in command line arguments, environment variables
|
|
and config files (<code>.git/config</code> (see <a href="git-config.html">git-config(1)</a>),
|
|
<a href="gitignore.html">gitignore(5)</a>, <a href="gitattributes.html">gitattributes(5)</a> and
|
|
<a href="gitmodules.html">gitmodules(5)</a>).
|
|
</p>
|
|
<div class="paragraph"><p>Note that Git at the core level treats path names simply as
|
|
sequences of non-NUL bytes, there are no path name encoding
|
|
conversions (except on Mac and Windows). Therefore, using
|
|
non-ASCII path names will mostly work even on platforms and file
|
|
systems that use legacy extended ASCII encodings. However,
|
|
repositories created on such systems will not work properly on
|
|
UTF-8-based systems (e.g. Linux, Mac, Windows) and vice versa.
|
|
Additionally, many Git-based tools simply assume path names to
|
|
be UTF-8 and will fail to display other encodings correctly.</p></div>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Commit log messages are typically encoded in UTF-8, but other
|
|
extended ASCII encodings are also supported. This includes
|
|
ISO-8859-x, CP125x and many others, but <em>not</em> UTF-16/32,
|
|
EBCDIC and CJK multi-byte encodings (GBK, Shift-JIS, Big5,
|
|
EUC-x, CP9xx etc.).
|
|
</p>
|
|
</li>
|
|
</ul></div>
|
|
<div class="paragraph"><p>Although we encourage that the commit log messages are encoded
|
|
in UTF-8, both the core and Git Porcelain are designed not to
|
|
force UTF-8 on projects. If all participants of a particular
|
|
project find it more convenient to use legacy encodings, Git
|
|
does not forbid it. However, there are a few things to keep in
|
|
mind.</p></div>
|
|
<div class="olist arabic"><ol class="arabic">
|
|
<li>
|
|
<p>
|
|
<em>git commit</em> and <em>git commit-tree</em> issues
|
|
a warning if the commit log message given to it does not look
|
|
like a valid UTF-8 string, unless you explicitly say your
|
|
project uses a legacy encoding. The way to say this is to
|
|
have <code>i18n.commitEncoding</code> in <code>.git/config</code> file, like this:
|
|
</p>
|
|
<div class="listingblock">
|
|
<div class="content">
|
|
<pre><code>[i18n]
|
|
commitEncoding = ISO-8859-1</code></pre>
|
|
</div></div>
|
|
<div class="paragraph"><p>Commit objects created with the above setting record the value
|
|
of <code>i18n.commitEncoding</code> in its <code>encoding</code> header. This is to
|
|
help other people who look at them later. Lack of this header
|
|
implies that the commit log message is encoded in UTF-8.</p></div>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<em>git log</em>, <em>git show</em>, <em>git blame</em> and friends look at the
|
|
<code>encoding</code> header of a commit object, and try to re-code the
|
|
log message into UTF-8 unless otherwise specified. You can
|
|
specify the desired output encoding with
|
|
<code>i18n.logOutputEncoding</code> in <code>.git/config</code> file, like this:
|
|
</p>
|
|
<div class="listingblock">
|
|
<div class="content">
|
|
<pre><code>[i18n]
|
|
logOutputEncoding = ISO-8859-1</code></pre>
|
|
</div></div>
|
|
<div class="paragraph"><p>If you do not have this configuration variable, the value of
|
|
<code>i18n.commitEncoding</code> is used instead.</p></div>
|
|
</li>
|
|
</ol></div>
|
|
<div class="paragraph"><p>Note that we deliberately chose not to re-code the commit log
|
|
message when a commit is made to force UTF-8 at the commit
|
|
object level, because re-coding to UTF-8 is not necessarily a
|
|
reversible operation.</p></div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_environment_and_configuration_variables">ENVIRONMENT AND CONFIGURATION VARIABLES</h2>
|
|
<div class="sectionbody">
|
|
<div class="paragraph"><p>The editor used to edit the commit log message will be chosen from the
|
|
<code>GIT_EDITOR</code> environment variable, the core.editor configuration variable, the
|
|
<code>VISUAL</code> environment variable, or the <code>EDITOR</code> environment variable (in that
|
|
order). See <a href="git-var.html">git-var(1)</a> for details.</p></div>
|
|
<div class="paragraph"><p>Everything above this line in this section isn’t included from the
|
|
<a href="git-config.html">git-config(1)</a> documentation. The content that follows is the
|
|
same as what’s found there:</p></div>
|
|
<div class="dlist"><dl>
|
|
<dt class="hdlist1">
|
|
commit.cleanup
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
This setting overrides the default of the <code>--cleanup</code> option in
|
|
<code>git commit</code>. See <a href="git-commit.html">git-commit(1)</a> for details. Changing the
|
|
default can be useful when you always want to keep lines that begin
|
|
with comment character <code>#</code> in your log message, in which case you
|
|
would do <code>git config commit.cleanup whitespace</code> (note that you will
|
|
have to remove the help lines that begin with <code>#</code> in the commit log
|
|
template yourself, if you do this).
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
commit.gpgSign
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
A boolean to specify whether all commits should be GPG signed.
|
|
Use of this option when doing operations such as rebase can
|
|
result in a large number of commits being signed. It may be
|
|
convenient to use an agent to avoid typing your GPG passphrase
|
|
several times.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
commit.status
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
A boolean to enable/disable inclusion of status information in the
|
|
commit message template when using an editor to prepare the commit
|
|
message. Defaults to true.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
commit.template
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
Specify the pathname of a file to use as the template for
|
|
new commit messages.
|
|
</p>
|
|
</dd>
|
|
<dt class="hdlist1">
|
|
commit.verbose
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
A boolean or int to specify the level of verbose with <code>git commit</code>.
|
|
See <a href="git-commit.html">git-commit(1)</a>.
|
|
</p>
|
|
</dd>
|
|
</dl></div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_hooks">HOOKS</h2>
|
|
<div class="sectionbody">
|
|
<div class="paragraph"><p>This command can run <code>commit-msg</code>, <code>prepare-commit-msg</code>, <code>pre-commit</code>,
|
|
<code>post-commit</code> and <code>post-rewrite</code> hooks. See <a href="githooks.html">githooks(5)</a> for more
|
|
information.</p></div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_files">FILES</h2>
|
|
<div class="sectionbody">
|
|
<div class="dlist"><dl>
|
|
<dt class="hdlist1">
|
|
<code>$GIT_DIR/COMMIT_EDITMSG</code>
|
|
</dt>
|
|
<dd>
|
|
<p>
|
|
This file contains the commit message of a commit in progress.
|
|
If <code>git commit</code> exits due to an error before creating a commit,
|
|
any commit message that has been provided by the user (e.g., in
|
|
an editor session) will be available in this file, but will be
|
|
overwritten by the next invocation of <code>git commit</code>.
|
|
</p>
|
|
</dd>
|
|
</dl></div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_see_also">SEE ALSO</h2>
|
|
<div class="sectionbody">
|
|
<div class="paragraph"><p><a href="git-add.html">git-add(1)</a>,
|
|
<a href="git-rm.html">git-rm(1)</a>,
|
|
<a href="git-mv.html">git-mv(1)</a>,
|
|
<a href="git-merge.html">git-merge(1)</a>,
|
|
<a href="git-commit-tree.html">git-commit-tree(1)</a></p></div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_git">GIT</h2>
|
|
<div class="sectionbody">
|
|
<div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div id="footnotes"><hr /></div>
|
|
<div id="footer">
|
|
<div id="footer-text">
|
|
Last updated
|
|
2022-10-08 14:40:28 PDT
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html>
|