git-log.html - pub/scm/git/git-htmldocs - Git at Google

 <?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 8.6.10" />
 <title>git-log(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 overriden 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-log(1) Manual Page
 </h1>
 <h2>NAME</h2>
 <div class="sectionbody">
 <p>git-log -
    Show commit logs
 </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 log</em> [&lt;options&gt;] [&lt;revision range&gt;] [[--] &lt;path&gt;&#8230;]</pre>
 <div class="attribution">
 </div></div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="_description">DESCRIPTION</h2>
 <div class="sectionbody">
 <div class="paragraph"><p>Shows the commit logs.</p></div>
 <div class="paragraph"><p>The command takes options applicable to the <code>git rev-list</code>
 command to control what is shown and how, and options applicable to
 the <code>git diff-*</code> commands to control how the changes
 each commit introduces are shown.</p></div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="_options">OPTIONS</h2>
 <div class="sectionbody">
 <div class="dlist"><dl>
 <dt class="hdlist1">
 --follow
 </dt>
 <dd>
 <p>
         Continue listing the history of a file beyond renames
         (works only for a single file).
 </p>
 </dd>
 <dt class="hdlist1">
 --no-decorate
 </dt>
 <dt class="hdlist1">
 --decorate[=short|full|auto|no]
 </dt>
 <dd>
 <p>
         Print out the ref names of any commits that are shown. If <em>short</em> is
         specified, the ref name prefixes <em>refs/heads/</em>, <em>refs/tags/</em> and
         <em>refs/remotes/</em> will not be printed. If <em>full</em> is specified, the
         full ref name (including prefix) will be printed. If <em>auto</em> is
         specified, then if the output is going to a terminal, the ref names
         are shown as if <em>short</em> were given, otherwise no ref names are
         shown. The default option is <em>short</em>.
 </p>
 </dd>
 <dt class="hdlist1">
 --decorate-refs=&lt;pattern&gt;
 </dt>
 <dt class="hdlist1">
 --decorate-refs-exclude=&lt;pattern&gt;
 </dt>
 <dd>
 <p>
         If no <code>--decorate-refs</code> is given, pretend as if all refs were
         included.  For each candidate, do not use it for decoration if it
         matches any patterns given to <code>--decorate-refs-exclude</code> or if it
         doesn&#8217;t match any of the patterns given to <code>--decorate-refs</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 --source
 </dt>
 <dd>
 <p>
         Print out the ref name given on the command line by which each
         commit was reached.
 </p>
 </dd>
 <dt class="hdlist1">
 --use-mailmap
 </dt>
 <dd>
 <p>
         Use mailmap file to map author and committer names and email
         addresses to canonical real names and email addresses. See
         <a href="git-shortlog.html">git-shortlog(1)</a>.
 </p>
 </dd>
 <dt class="hdlist1">
 --full-diff
 </dt>
 <dd>
 <p>
         Without this flag, <code>git log -p &lt;path&gt;...</code> shows commits that
         touch the specified paths, and diffs about the same specified
         paths.  With this, the full diff is shown for commits that touch
         the specified paths; this means that "&lt;path&gt;&#8230;" limits only
         commits, and doesn&#8217;t limit diff for those commits.
 </p>
 <div class="paragraph"><p>Note that this affects all diff-based output types, e.g. those
 produced by <code>--stat</code>, etc.</p></div>
 </dd>
 <dt class="hdlist1">
 --log-size
 </dt>
 <dd>
 <p>
         Include a line &#8220;log size &lt;number&gt;&#8221; in the output for each commit,
         where &lt;number&gt; is the length of that commit&#8217;s message in bytes.
         Intended to speed up tools that read log messages from <code>git log</code>
         output by allowing them to allocate space in advance.
 </p>
 </dd>
 <dt class="hdlist1">
 -L &lt;start&gt;,&lt;end&gt;:&lt;file&gt;
 </dt>
 <dt class="hdlist1">
 -L :&lt;funcname&gt;:&lt;file&gt;
 </dt>
 <dd>
 <p>
         Trace the evolution of the line range given by "&lt;start&gt;,&lt;end&gt;"
         (or the function name regex &lt;funcname&gt;) within the &lt;file&gt;.  You may
         not give any pathspec limiters.  This is currently limited to
         a walk starting from a single revision, i.e., you may only
         give zero or one positive revision arguments.
         You can specify this option more than once.
 </p>
 <div class="paragraph"><p>&lt;start&gt; and &lt;end&gt; can take one of these forms:</p></div>
 <div class="ulist"><ul>
 <li>
 <p>
 number
 </p>
 <div class="paragraph"><p>If &lt;start&gt; or &lt;end&gt; is a number, it specifies an
 absolute line number (lines count from 1).</p></div>
 </li>
 <li>
 <p>
 /regex/
 </p>
 <div class="paragraph"><p>This form will use the first line matching the given
 POSIX regex. If &lt;start&gt; is a regex, it will search from the end of
 the previous <code>-L</code> range, if any, otherwise from the start of file.
 If &lt;start&gt; is &#8220;^/regex/&#8221;, it will search from the start of file.
 If &lt;end&gt; is a regex, it will search
 starting at the line given by &lt;start&gt;.</p></div>
 </li>
 <li>
 <p>
 +offset or -offset
 </p>
 <div class="paragraph"><p>This is only valid for &lt;end&gt; and will specify a number
 of lines before or after the line given by &lt;start&gt;.</p></div>
 </li>
 </ul></div>
 <div class="paragraph"><p>If &#8220;:&lt;funcname&gt;&#8221; is given in place of &lt;start&gt; and &lt;end&gt;, it is a
 regular expression that denotes the range from the first funcname line
 that matches &lt;funcname&gt;, up to the next funcname line. &#8220;:&lt;funcname&gt;&#8221;
 searches from the end of the previous <code>-L</code> range, if any, otherwise
 from the start of file. &#8220;^:&lt;funcname&gt;&#8221; searches from the start of
 file.</p></div>
 </dd>
 <dt class="hdlist1">
 &lt;revision range&gt;
 </dt>
 <dd>
 <p>
         Show only commits in the specified revision range.  When no
         &lt;revision range&gt; is specified, it defaults to <code>HEAD</code> (i.e. the
         whole history leading to the current commit).  <code>origin..HEAD</code>
         specifies all the commits reachable from the current commit
         (i.e. <code>HEAD</code>), but not from <code>origin</code>. For a complete list of
         ways to spell &lt;revision range&gt;, see the <em>Specifying Ranges</em>
         section of <a href="gitrevisions.html">gitrevisions(7)</a>.
 </p>
 </dd>
 <dt class="hdlist1">
 [--] &lt;path&gt;&#8230;
 </dt>
 <dd>
 <p>
         Show only commits that are enough to explain how the files
         that match the specified paths came to be.  See <em>History
         Simplification</em> below for details and other simplification
         modes.
 </p>
 <div class="paragraph"><p>Paths may need to be prefixed with <code>--</code> to separate them from
 options or the revision range, when confusion arises.</p></div>
 </dd>
 </dl></div>
 <div class="sect2">
 <h3 id="_commit_limiting">Commit Limiting</h3>
 <div class="paragraph"><p>Besides specifying a range of commits that should be listed using the
 special notations explained in the description, additional commit
 limiting may be applied.</p></div>
 <div class="paragraph"><p>Using more options generally further limits the output (e.g.
 <code>--since=&lt;date1&gt;</code> limits to commits newer than <code>&lt;date1&gt;</code>, and using it
 with <code>--grep=&lt;pattern&gt;</code> further limits to commits whose log message
 has a line that matches <code>&lt;pattern&gt;</code>), unless otherwise noted.</p></div>
 <div class="paragraph"><p>Note that these are applied before commit
 ordering and formatting options, such as <code>--reverse</code>.</p></div>
 <div class="openblock">
 <div class="content">
 <div class="dlist"><dl>
 <dt class="hdlist1">
 -&lt;number&gt;
 </dt>
 <dt class="hdlist1">
 -n &lt;number&gt;
 </dt>
 <dt class="hdlist1">
 --max-count=&lt;number&gt;
 </dt>
 <dd>
 <p>
         Limit the number of commits to output.
 </p>
 </dd>
 <dt class="hdlist1">
 --skip=&lt;number&gt;
 </dt>
 <dd>
 <p>
         Skip <em>number</em> commits before starting to show the commit output.
 </p>
 </dd>
 <dt class="hdlist1">
 --since=&lt;date&gt;
 </dt>
 <dt class="hdlist1">
 --after=&lt;date&gt;
 </dt>
 <dd>
 <p>
         Show commits more recent than a specific date.
 </p>
 </dd>
 <dt class="hdlist1">
 --until=&lt;date&gt;
 </dt>
 <dt class="hdlist1">
 --before=&lt;date&gt;
 </dt>
 <dd>
 <p>
         Show commits older than a specific date.
 </p>
 </dd>
 <dt class="hdlist1">
 --author=&lt;pattern&gt;
 </dt>
 <dt class="hdlist1">
 --committer=&lt;pattern&gt;
 </dt>
 <dd>
 <p>
         Limit the commits output to ones with author/committer
         header lines that match the specified pattern (regular
         expression).  With more than one <code>--author=&lt;pattern&gt;</code>,
         commits whose author matches any of the given patterns are
         chosen (similarly for multiple <code>--committer=&lt;pattern&gt;</code>).
 </p>
 </dd>
 <dt class="hdlist1">
 --grep-reflog=&lt;pattern&gt;
 </dt>
 <dd>
 <p>
         Limit the commits output to ones with reflog entries that
         match the specified pattern (regular expression). With
         more than one <code>--grep-reflog</code>, commits whose reflog message
         matches any of the given patterns are chosen.  It is an
         error to use this option unless <code>--walk-reflogs</code> is in use.
 </p>
 </dd>
 <dt class="hdlist1">
 --grep=&lt;pattern&gt;
 </dt>
 <dd>
 <p>
         Limit the commits output to ones with log message that
         matches the specified pattern (regular expression).  With
         more than one <code>--grep=&lt;pattern&gt;</code>, commits whose message
         matches any of the given patterns are chosen (but see
         <code>--all-match</code>).
 </p>
 <div class="paragraph"><p>When <code>--show-notes</code> is in effect, the message from the notes is
 matched as if it were part of the log message.</p></div>
 </dd>
 <dt class="hdlist1">
 --all-match
 </dt>
 <dd>
 <p>
         Limit the commits output to ones that match all given <code>--grep</code>,
         instead of ones that match at least one.
 </p>
 </dd>
 <dt class="hdlist1">
 --invert-grep
 </dt>
 <dd>
 <p>
         Limit the commits output to ones with log message that do not
         match the pattern specified with <code>--grep=&lt;pattern&gt;</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 -i
 </dt>
 <dt class="hdlist1">
 --regexp-ignore-case
 </dt>
 <dd>
 <p>
         Match the regular expression limiting patterns without regard to letter
         case.
 </p>
 </dd>
 <dt class="hdlist1">
 --basic-regexp
 </dt>
 <dd>
 <p>
         Consider the limiting patterns to be basic regular expressions;
         this is the default.
 </p>
 </dd>
 <dt class="hdlist1">
 -E
 </dt>
 <dt class="hdlist1">
 --extended-regexp
 </dt>
 <dd>
 <p>
         Consider the limiting patterns to be extended regular expressions
         instead of the default basic regular expressions.
 </p>
 </dd>
 <dt class="hdlist1">
 -F
 </dt>
 <dt class="hdlist1">
 --fixed-strings
 </dt>
 <dd>
 <p>
         Consider the limiting patterns to be fixed strings (don&#8217;t interpret
         pattern as a regular expression).
 </p>
 </dd>
 <dt class="hdlist1">
 -P
 </dt>
 <dt class="hdlist1">
 --perl-regexp
 </dt>
 <dd>
 <p>
         Consider the limiting patterns to be Perl-compatible regular
         expressions.
 </p>
 <div class="paragraph"><p>Support for these types of regular expressions is an optional
 compile-time dependency. If Git wasn&#8217;t compiled with support for them
 providing this option will cause it to die.</p></div>
 </dd>
 <dt class="hdlist1">
 --remove-empty
 </dt>
 <dd>
 <p>
         Stop when a given path disappears from the tree.
 </p>
 </dd>
 <dt class="hdlist1">
 --merges
 </dt>
 <dd>
 <p>
         Print only merge commits. This is exactly the same as <code>--min-parents=2</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 --no-merges
 </dt>
 <dd>
 <p>
         Do not print commits with more than one parent. This is
         exactly the same as <code>--max-parents=1</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 --min-parents=&lt;number&gt;
 </dt>
 <dt class="hdlist1">
 --max-parents=&lt;number&gt;
 </dt>
 <dt class="hdlist1">
 --no-min-parents
 </dt>
 <dt class="hdlist1">
 --no-max-parents
 </dt>
 <dd>
 <p>
         Show only commits which have at least (or at most) that many parent
         commits. In particular, <code>--max-parents=1</code> is the same as <code>--no-merges</code>,
         <code>--min-parents=2</code> is the same as <code>--merges</code>.  <code>--max-parents=0</code>
         gives all root commits and <code>--min-parents=3</code> all octopus merges.
 </p>
 <div class="paragraph"><p><code>--no-min-parents</code> and <code>--no-max-parents</code> reset these limits (to no limit)
 again.  Equivalent forms are <code>--min-parents=0</code> (any commit has 0 or more
 parents) and <code>--max-parents=-1</code> (negative numbers denote no upper limit).</p></div>
 </dd>
 <dt class="hdlist1">
 --first-parent
 </dt>
 <dd>
 <p>
         Follow only the first parent commit upon seeing a merge
         commit.  This option can give a better overview when
         viewing the evolution of a particular topic branch,
         because merges into a topic branch tend to be only about
         adjusting to updated upstream from time to time, and
         this option allows you to ignore the individual commits
         brought in to your history by such a merge. Cannot be
         combined with --bisect.
 </p>
 </dd>
 <dt class="hdlist1">
 --not
 </dt>
 <dd>
 <p>
         Reverses the meaning of the <em>&#94;</em> prefix (or lack thereof)
         for all following revision specifiers, up to the next <code>--not</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 --all
 </dt>
 <dd>
 <p>
         Pretend as if all the refs in <code>refs/</code>, along with <code>HEAD</code>, are
         listed on the command line as <em>&lt;commit&gt;</em>.
 </p>
 </dd>
 <dt class="hdlist1">
 --branches[=&lt;pattern&gt;]
 </dt>
 <dd>
 <p>
         Pretend as if all the refs in <code>refs/heads</code> are listed
         on the command line as <em>&lt;commit&gt;</em>. If <em>&lt;pattern&gt;</em> is given, limit
         branches to ones matching given shell glob. If pattern lacks <em>?</em>,
         <em>&#42;</em>, or <em>[</em>, <em>/&#42;</em> at the end is implied.
 </p>
 </dd>
 <dt class="hdlist1">
 --tags[=&lt;pattern&gt;]
 </dt>
 <dd>
 <p>
         Pretend as if all the refs in <code>refs/tags</code> are listed
         on the command line as <em>&lt;commit&gt;</em>. If <em>&lt;pattern&gt;</em> is given, limit
         tags to ones matching given shell glob. If pattern lacks <em>?</em>, <em>&#42;</em>,
         or <em>[</em>, <em>/&#42;</em> at the end is implied.
 </p>
 </dd>
 <dt class="hdlist1">
 --remotes[=&lt;pattern&gt;]
 </dt>
 <dd>
 <p>
         Pretend as if all the refs in <code>refs/remotes</code> are listed
         on the command line as <em>&lt;commit&gt;</em>. If <em>&lt;pattern&gt;</em> is given, limit
         remote-tracking branches to ones matching given shell glob.
         If pattern lacks <em>?</em>, <em>&#42;</em>, or <em>[</em>, <em>/&#42;</em> at the end is implied.
 </p>
 </dd>
 <dt class="hdlist1">
 --glob=&lt;glob-pattern&gt;
 </dt>
 <dd>
 <p>
         Pretend as if all the refs matching shell glob <em>&lt;glob-pattern&gt;</em>
         are listed on the command line as <em>&lt;commit&gt;</em>. Leading <em>refs/</em>,
         is automatically prepended if missing. If pattern lacks <em>?</em>, <em>&#42;</em>,
         or <em>[</em>, <em>/&#42;</em> at the end is implied.
 </p>
 </dd>
 <dt class="hdlist1">
 --exclude=&lt;glob-pattern&gt;
 </dt>
 <dd>
 <p>
         Do not include refs matching <em>&lt;glob-pattern&gt;</em> that the next <code>--all</code>,
         <code>--branches</code>, <code>--tags</code>, <code>--remotes</code>, or <code>--glob</code> would otherwise
         consider. Repetitions of this option accumulate exclusion patterns
         up to the next <code>--all</code>, <code>--branches</code>, <code>--tags</code>, <code>--remotes</code>, or
         <code>--glob</code> option (other options or arguments do not clear
         accumulated patterns).
 </p>
 <div class="paragraph"><p>The patterns given should not begin with <code>refs/heads</code>, <code>refs/tags</code>, or
 <code>refs/remotes</code> when applied to <code>--branches</code>, <code>--tags</code>, or <code>--remotes</code>,
 respectively, and they must begin with <code>refs/</code> when applied to <code>--glob</code>
 or <code>--all</code>. If a trailing <em>/&#42;</em> is intended, it must be given
 explicitly.</p></div>
 </dd>
 <dt class="hdlist1">
 --reflog
 </dt>
 <dd>
 <p>
         Pretend as if all objects mentioned by reflogs are listed on the
         command line as <code>&lt;commit&gt;</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 --single-worktree
 </dt>
 <dd>
 <p>
         By default, all working trees will be examined by the
         following options when there are more than one (see
         <a href="git-worktree.html">git-worktree(1)</a>): <code>--all</code>, <code>--reflog</code> and
         <code>--indexed-objects</code>.
         This option forces them to examine the current working tree
         only.
 </p>
 </dd>
 <dt class="hdlist1">
 --ignore-missing
 </dt>
 <dd>
 <p>
         Upon seeing an invalid object name in the input, pretend as if
         the bad input was not given.
 </p>
 </dd>
 <dt class="hdlist1">
 --bisect
 </dt>
 <dd>
 <p>
         Pretend as if the bad bisection ref <code>refs/bisect/bad</code>
         was listed and as if it was followed by <code>--not</code> and the good
         bisection refs <code>refs/bisect/good-*</code> on the command
         line. Cannot be combined with --first-parent.
 </p>
 </dd>
 <dt class="hdlist1">
 --stdin
 </dt>
 <dd>
 <p>
         In addition to the <em>&lt;commit&gt;</em> listed on the command
         line, read them from the standard input. If a <code>--</code> separator is
         seen, stop reading commits and start reading paths to limit the
         result.
 </p>
 </dd>
 <dt class="hdlist1">
 --cherry-mark
 </dt>
 <dd>
 <p>
         Like <code>--cherry-pick</code> (see below) but mark equivalent commits
         with <code>=</code> rather than omitting them, and inequivalent ones with <code>+</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 --cherry-pick
 </dt>
 <dd>
 <p>
         Omit any commit that introduces the same change as
         another commit on the &#8220;other side&#8221; when the set of
         commits are limited with symmetric difference.
 </p>
 <div class="paragraph"><p>For example, if you have two branches, <code>A</code> and <code>B</code>, a usual way
 to list all commits on only one side of them is with
 <code>--left-right</code> (see the example below in the description of
 the <code>--left-right</code> option). However, it shows the commits that were
 cherry-picked from the other branch (for example, &#8220;3rd on b&#8221; may be
 cherry-picked from branch A). With this option, such pairs of commits are
 excluded from the output.</p></div>
 </dd>
 <dt class="hdlist1">
 --left-only
 </dt>
 <dt class="hdlist1">
 --right-only
 </dt>
 <dd>
 <p>
         List only commits on the respective side of a symmetric difference,
         i.e. only those which would be marked <code>&lt;</code> resp. <code>&gt;</code> by
         <code>--left-right</code>.
 </p>
 <div class="paragraph"><p>For example, <code>--cherry-pick --right-only A...B</code> omits those
 commits from <code>B</code> which are in <code>A</code> or are patch-equivalent to a commit in
 <code>A</code>. In other words, this lists the <code>+</code> commits from <code>git cherry A B</code>.
 More precisely, <code>--cherry-pick --right-only --no-merges</code> gives the exact
 list.</p></div>
 </dd>
 <dt class="hdlist1">
 --cherry
 </dt>
 <dd>
 <p>
         A synonym for <code>--right-only --cherry-mark --no-merges</code>; useful to
         limit the output to the commits on our side and mark those that
         have been applied to the other side of a forked history with
         <code>git log --cherry upstream...mybranch</code>, similar to
         <code>git cherry upstream mybranch</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 -g
 </dt>
 <dt class="hdlist1">
 --walk-reflogs
 </dt>
 <dd>
 <p>
         Instead of walking the commit ancestry chain, walk
         reflog entries from the most recent one to older ones.
         When this option is used you cannot specify commits to
         exclude (that is, <em>&#94;commit</em>, <em>commit1..commit2</em>,
         and <em>commit1...commit2</em> notations cannot be used).
 </p>
 <div class="paragraph"><p>With <code>--pretty</code> format other than <code>oneline</code> (for obvious reasons),
 this causes the output to have two extra lines of information
 taken from the reflog.  The reflog designator in the output may be shown
 as <code>ref@{Nth}</code> (where <code>Nth</code> is the reverse-chronological index in the
 reflog) or as <code>ref@{timestamp}</code> (with the timestamp for that entry),
 depending on a few rules:</p></div>
 <div class="openblock">
 <div class="content">
 <div class="olist arabic"><ol class="arabic">
 <li>
 <p>
 If the starting point is specified as <code>ref@{Nth}</code>, show the index
 format.
 </p>
 </li>
 <li>
 <p>
 If the starting point was specified as <code>ref@{now}</code>, show the
 timestamp format.
 </p>
 </li>
 <li>
 <p>
 If neither was used, but <code>--date</code> was given on the command line, show
 the timestamp in the format requested by <code>--date</code>.
 </p>
 </li>
 <li>
 <p>
 Otherwise, show the index format.
 </p>
 </li>
 </ol></div>
 </div></div>
 <div class="paragraph"><p>Under <code>--pretty=oneline</code>, the commit message is
 prefixed with this information on the same line.
 This option cannot be combined with <code>--reverse</code>.
 See also <a href="git-reflog.html">git-reflog(1)</a>.</p></div>
 </dd>
 <dt class="hdlist1">
 --merge
 </dt>
 <dd>
 <p>
         After a failed merge, show refs that touch files having a
         conflict and don&#8217;t exist on all heads to merge.
 </p>
 </dd>
 <dt class="hdlist1">
 --boundary
 </dt>
 <dd>
 <p>
         Output excluded boundary commits. Boundary commits are
         prefixed with <code>-</code>.
 </p>
 </dd>
 </dl></div>
 </div></div>
 </div>
 <div class="sect2">
 <h3 id="_history_simplification">History Simplification</h3>
 <div class="paragraph"><p>Sometimes you are only interested in parts of the history, for example the
 commits modifying a particular &lt;path&gt;. But there are two parts of
 <em>History Simplification</em>, one part is selecting the commits and the other
 is how to do it, as there are various strategies to simplify the history.</p></div>
 <div class="paragraph"><p>The following options select the commits to be shown:</p></div>
 <div class="dlist"><dl>
 <dt class="hdlist1">
 &lt;paths&gt;
 </dt>
 <dd>
 <p>
         Commits modifying the given &lt;paths&gt; are selected.
 </p>
 </dd>
 <dt class="hdlist1">
 --simplify-by-decoration
 </dt>
 <dd>
 <p>
         Commits that are referred by some branch or tag are selected.
 </p>
 </dd>
 </dl></div>
 <div class="paragraph"><p>Note that extra commits can be shown to give a meaningful history.</p></div>
 <div class="paragraph"><p>The following options affect the way the simplification is performed:</p></div>
 <div class="dlist"><dl>
 <dt class="hdlist1">
 Default mode
 </dt>
 <dd>
 <p>
         Simplifies the history to the simplest history explaining the
         final state of the tree. Simplest because it prunes some side
         branches if the end result is the same (i.e. merging branches
         with the same content)
 </p>
 </dd>
 <dt class="hdlist1">
 --full-history
 </dt>
 <dd>
 <p>
         Same as the default mode, but does not prune some history.
 </p>
 </dd>
 <dt class="hdlist1">
 --dense
 </dt>
 <dd>
 <p>
         Only the selected commits are shown, plus some to have a
         meaningful history.
 </p>
 </dd>
 <dt class="hdlist1">
 --sparse
 </dt>
 <dd>
 <p>
         All commits in the simplified history are shown.
 </p>
 </dd>
 <dt class="hdlist1">
 --simplify-merges
 </dt>
 <dd>
 <p>
         Additional option to <code>--full-history</code> to remove some needless
         merges from the resulting history, as there are no selected
         commits contributing to this merge.
 </p>
 </dd>
 <dt class="hdlist1">
 --ancestry-path
 </dt>
 <dd>
 <p>
         When given a range of commits to display (e.g. <em>commit1..commit2</em>
         or <em>commit2 &#94;commit1</em>), only display commits that exist
         directly on the ancestry chain between the <em>commit1</em> and
         <em>commit2</em>, i.e. commits that are both descendants of <em>commit1</em>,
         and ancestors of <em>commit2</em>.
 </p>
 </dd>
 </dl></div>
 <div class="paragraph"><p>A more detailed explanation follows.</p></div>
 <div class="paragraph"><p>Suppose you specified <code>foo</code> as the &lt;paths&gt;.  We shall call commits
 that modify <code>foo</code> !TREESAME, and the rest TREESAME.  (In a diff
 filtered for <code>foo</code>, they look different and equal, respectively.)</p></div>
 <div class="paragraph"><p>In the following, we will always refer to the same example history to
 illustrate the differences between simplification settings.  We assume
 that you are filtering for a file <code>foo</code> in this commit graph:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code>          .-A---M---N---O---P---Q
          /     /   /   /   /   /
         I     B   C   D   E   Y
          \   /   /   /   /   /
           `-------------'   X</code></pre>
 </div></div>
 <div class="paragraph"><p>The horizontal line of history A---Q is taken to be the first parent of
 each merge.  The commits are:</p></div>
 <div class="ulist"><ul>
 <li>
 <p>
 <code>I</code> is the initial commit, in which <code>foo</code> exists with contents
   &#8220;asdf&#8221;, and a file <code>quux</code> exists with contents &#8220;quux&#8221;. Initial
   commits are compared to an empty tree, so <code>I</code> is !TREESAME.
 </p>
 </li>
 <li>
 <p>
 In <code>A</code>, <code>foo</code> contains just &#8220;foo&#8221;.
 </p>
 </li>
 <li>
 <p>
 <code>B</code> contains the same change as <code>A</code>.  Its merge <code>M</code> is trivial and
   hence TREESAME to all parents.
 </p>
 </li>
 <li>
 <p>
 <code>C</code> does not change <code>foo</code>, but its merge <code>N</code> changes it to &#8220;foobar&#8221;,
   so it is not TREESAME to any parent.
 </p>
 </li>
 <li>
 <p>
 <code>D</code> sets <code>foo</code> to &#8220;baz&#8221;. Its merge <code>O</code> combines the strings from
   <code>N</code> and <code>D</code> to &#8220;foobarbaz&#8221;; i.e., it is not TREESAME to any parent.
 </p>
 </li>
 <li>
 <p>
 <code>E</code> changes <code>quux</code> to &#8220;xyzzy&#8221;, and its merge <code>P</code> combines the
   strings to &#8220;quux xyzzy&#8221;. <code>P</code> is TREESAME to <code>O</code>, but not to <code>E</code>.
 </p>
 </li>
 <li>
 <p>
 <code>X</code> is an independent root commit that added a new file <code>side</code>, and <code>Y</code>
   modified it. <code>Y</code> is TREESAME to <code>X</code>. Its merge <code>Q</code> added <code>side</code> to <code>P</code>, and
   <code>Q</code> is TREESAME to <code>P</code>, but not to <code>Y</code>.
 </p>
 </li>
 </ul></div>
 <div class="paragraph"><p><code>rev-list</code> walks backwards through history, including or excluding
 commits based on whether <code>--full-history</code> and/or parent rewriting
 (via <code>--parents</code> or <code>--children</code>) are used. The following settings
 are available.</p></div>
 <div class="dlist"><dl>
 <dt class="hdlist1">
 Default mode
 </dt>
 <dd>
 <p>
         Commits are included if they are not TREESAME to any parent
         (though this can be changed, see <code>--sparse</code> below).  If the
         commit was a merge, and it was TREESAME to one parent, follow
         only that parent.  (Even if there are several TREESAME
         parents, follow only one of them.)  Otherwise, follow all
         parents.
 </p>
 <div class="paragraph"><p>This results in:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code>          .-A---N---O
          /     /   /
         I---------D</code></pre>
 </div></div>
 <div class="paragraph"><p>Note how the rule to only follow the TREESAME parent, if one is
 available, removed <code>B</code> from consideration entirely.  <code>C</code> was
 considered via <code>N</code>, but is TREESAME.  Root commits are compared to an
 empty tree, so <code>I</code> is !TREESAME.</p></div>
 <div class="paragraph"><p>Parent/child relations are only visible with <code>--parents</code>, but that does
 not affect the commits selected in default mode, so we have shown the
 parent lines.</p></div>
 </dd>
 <dt class="hdlist1">
 --full-history without parent rewriting
 </dt>
 <dd>
 <p>
         This mode differs from the default in one point: always follow
         all parents of a merge, even if it is TREESAME to one of them.
         Even if more than one side of the merge has commits that are
         included, this does not imply that the merge itself is!  In
         the example, we get
 </p>
 <div class="listingblock">
 <div class="content">
 <pre><code>        I  A  B  N  D  O  P  Q</code></pre>
 </div></div>
 <div class="paragraph"><p><code>M</code> was excluded because it is TREESAME to both parents.  <code>E</code>,
 <code>C</code> and <code>B</code> were all walked, but only <code>B</code> was !TREESAME, so the others
 do not appear.</p></div>
 <div class="paragraph"><p>Note that without parent rewriting, it is not really possible to talk
 about the parent/child relationships between the commits, so we show
 them disconnected.</p></div>
 </dd>
 <dt class="hdlist1">
 --full-history with parent rewriting
 </dt>
 <dd>
 <p>
         Ordinary commits are only included if they are !TREESAME
         (though this can be changed, see <code>--sparse</code> below).
 </p>
 <div class="paragraph"><p>Merges are always included.  However, their parent list is rewritten:
 Along each parent, prune away commits that are not included
 themselves.  This results in</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code>          .-A---M---N---O---P---Q
          /     /   /   /   /
         I     B   /   D   /
          \   /   /   /   /
           `-------------'</code></pre>
 </div></div>
 <div class="paragraph"><p>Compare to <code>--full-history</code> without rewriting above.  Note that <code>E</code>
 was pruned away because it is TREESAME, but the parent list of P was
 rewritten to contain <code>E</code>'s parent <code>I</code>.  The same happened for <code>C</code> and
 <code>N</code>, and <code>X</code>, <code>Y</code> and <code>Q</code>.</p></div>
 </dd>
 </dl></div>
 <div class="paragraph"><p>In addition to the above settings, you can change whether TREESAME
 affects inclusion:</p></div>
 <div class="dlist"><dl>
 <dt class="hdlist1">
 --dense
 </dt>
 <dd>
 <p>
         Commits that are walked are included if they are not TREESAME
         to any parent.
 </p>
 </dd>
 <dt class="hdlist1">
 --sparse
 </dt>
 <dd>
 <p>
         All commits that are walked are included.
 </p>
 <div class="paragraph"><p>Note that without <code>--full-history</code>, this still simplifies merges: if
 one of the parents is TREESAME, we follow only that one, so the other
 sides of the merge are never walked.</p></div>
 </dd>
 <dt class="hdlist1">
 --simplify-merges
 </dt>
 <dd>
 <p>
         First, build a history graph in the same way that
         <code>--full-history</code> with parent rewriting does (see above).
 </p>
 <div class="paragraph"><p>Then simplify each commit <code>C</code> to its replacement <code>C'</code> in the final
 history according to the following rules:</p></div>
 <div class="openblock">
 <div class="content">
 <div class="ulist"><ul>
 <li>
 <p>
 Set <code>C'</code> to <code>C</code>.
 </p>
 </li>
 <li>
 <p>
 Replace each parent <code>P</code> of <code>C'</code> with its simplification <code>P'</code>.  In
   the process, drop parents that are ancestors of other parents or that are
   root commits TREESAME to an empty tree, and remove duplicates, but take care
   to never drop all parents that we are TREESAME to.
 </p>
 </li>
 <li>
 <p>
 If after this parent rewriting, <code>C'</code> is a root or merge commit (has
   zero or &gt;1 parents), a boundary commit, or !TREESAME, it remains.
   Otherwise, it is replaced with its only parent.
 </p>
 </li>
 </ul></div>
 </div></div>
 <div class="paragraph"><p>The effect of this is best shown by way of comparing to
 <code>--full-history</code> with parent rewriting.  The example turns into:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code>          .-A---M---N---O
          /     /       /
         I     B       D
          \   /       /
           `---------'</code></pre>
 </div></div>
 <div class="paragraph"><p>Note the major differences in <code>N</code>, <code>P</code>, and <code>Q</code> over <code>--full-history</code>:</p></div>
 <div class="openblock">
 <div class="content">
 <div class="ulist"><ul>
 <li>
 <p>
 <code>N</code>'s parent list had <code>I</code> removed, because it is an ancestor of the
   other parent <code>M</code>.  Still, <code>N</code> remained because it is !TREESAME.
 </p>
 </li>
 <li>
 <p>
 <code>P</code>'s parent list similarly had <code>I</code> removed.  <code>P</code> was then
   removed completely, because it had one parent and is TREESAME.
 </p>
 </li>
 <li>
 <p>
 <code>Q</code>'s parent list had <code>Y</code> simplified to <code>X</code>. <code>X</code> was then removed, because it
   was a TREESAME root. <code>Q</code> was then removed completely, because it had one
   parent and is TREESAME.
 </p>
 </li>
 </ul></div>
 </div></div>
 </dd>
 </dl></div>
 <div class="paragraph"><p>Finally, there is a fifth simplification mode available:</p></div>
 <div class="dlist"><dl>
 <dt class="hdlist1">
 --ancestry-path
 </dt>
 <dd>
 <p>
         Limit the displayed commits to those directly on the ancestry
         chain between the &#8220;from&#8221; and &#8220;to&#8221; commits in the given commit
         range. I.e. only display commits that are ancestor of the &#8220;to&#8221;
         commit and descendants of the &#8220;from&#8221; commit.
 </p>
 <div class="paragraph"><p>As an example use case, consider the following commit history:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code>            D---E-------F
            /     \       \
           B---C---G---H---I---J
          /                     \
         A-------K---------------L--M</code></pre>
 </div></div>
 <div class="paragraph"><p>A regular <em>D..M</em> computes the set of commits that are ancestors of <code>M</code>,
 but excludes the ones that are ancestors of <code>D</code>. This is useful to see
 what happened to the history leading to <code>M</code> since <code>D</code>, in the sense
 that &#8220;what does <code>M</code> have that did not exist in <code>D</code>&#8221;. The result in this
 example would be all the commits, except <code>A</code> and <code>B</code> (and <code>D</code> itself,
 of course).</p></div>
 <div class="paragraph"><p>When we want to find out what commits in <code>M</code> are contaminated with the
 bug introduced by <code>D</code> and need fixing, however, we might want to view
 only the subset of <em>D..M</em> that are actually descendants of <code>D</code>, i.e.
 excluding <code>C</code> and <code>K</code>. This is exactly what the <code>--ancestry-path</code>
 option does. Applied to the <em>D..M</em> range, it results in:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code>                E-------F
                  \       \
                   G---H---I---J
                                \
                                 L--M</code></pre>
 </div></div>
 </dd>
 </dl></div>
 <div class="paragraph"><p>The <code>--simplify-by-decoration</code> option allows you to view only the
 big picture of the topology of the history, by omitting commits
 that are not referenced by tags.  Commits are marked as !TREESAME
 (in other words, kept after history simplification rules described
 above) if (1) they are referenced by tags, or (2) they change the
 contents of the paths given on the command line.  All other
 commits are marked as TREESAME (subject to be simplified away).</p></div>
 </div>
 <div class="sect2">
 <h3 id="_commit_ordering">Commit Ordering</h3>
 <div class="paragraph"><p>By default, the commits are shown in reverse chronological order.</p></div>
 <div class="dlist"><dl>
 <dt class="hdlist1">
 --date-order
 </dt>
 <dd>
 <p>
         Show no parents before all of its children are shown, but
         otherwise show commits in the commit timestamp order.
 </p>
 </dd>
 <dt class="hdlist1">
 --author-date-order
 </dt>
 <dd>
 <p>
         Show no parents before all of its children are shown, but
         otherwise show commits in the author timestamp order.
 </p>
 </dd>
 <dt class="hdlist1">
 --topo-order
 </dt>
 <dd>
 <p>
         Show no parents before all of its children are shown, and
         avoid showing commits on multiple lines of history
         intermixed.
 </p>
 <div class="paragraph"><p>For example, in a commit history like this:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code>    ---1----2----4----7
         \              \
          3----5----6----8---</code></pre>
 </div></div>
 <div class="paragraph"><p>where the numbers denote the order of commit timestamps, <code>git
 rev-list</code> and friends with <code>--date-order</code> show the commits in the
 timestamp order: 8 7 6 5 4 3 2 1.</p></div>
 <div class="paragraph"><p>With <code>--topo-order</code>, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5
 3 1); some older commits are shown before newer ones in order to
 avoid showing the commits from two parallel development track mixed
 together.</p></div>
 </dd>
 <dt class="hdlist1">
 --reverse
 </dt>
 <dd>
 <p>
         Output the commits chosen to be shown (see Commit Limiting
         section above) in reverse order. Cannot be combined with
         <code>--walk-reflogs</code>.
 </p>
 </dd>
 </dl></div>
 </div>
 <div class="sect2">
 <h3 id="_object_traversal">Object Traversal</h3>
 <div class="paragraph"><p>These options are mostly targeted for packing of Git repositories.</p></div>
 <div class="dlist"><dl>
 <dt class="hdlist1">
 --no-walk[=(sorted|unsorted)]
 </dt>
 <dd>
 <p>
         Only show the given commits, but do not traverse their ancestors.
         This has no effect if a range is specified. If the argument
         <code>unsorted</code> is given, the commits are shown in the order they were
         given on the command line. Otherwise (if <code>sorted</code> or no argument
         was given), the commits are shown in reverse chronological order
         by commit time.
         Cannot be combined with <code>--graph</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 --do-walk
 </dt>
 <dd>
 <p>
         Overrides a previous <code>--no-walk</code>.
 </p>
 </dd>
 </dl></div>
 </div>
 <div class="sect2">
 <h3 id="_commit_formatting">Commit Formatting</h3>
 <div class="dlist"><dl>
 <dt class="hdlist1">
 --pretty[=&lt;format&gt;]
 </dt>
 <dt class="hdlist1">
 --format=&lt;format&gt;
 </dt>
 <dd>
 <p>
         Pretty-print the contents of the commit logs in a given format,
         where <em>&lt;format&gt;</em> can be one of <em>oneline</em>, <em>short</em>, <em>medium</em>,
         <em>full</em>, <em>fuller</em>, <em>email</em>, <em>raw</em>, <em>format:&lt;string&gt;</em>
         and <em>tformat:&lt;string&gt;</em>.  When <em>&lt;format&gt;</em> is none of the above,
         and has <em>%placeholder</em> in it, it acts as if
         <em>--pretty=tformat:&lt;format&gt;</em> were given.
 </p>
 <div class="paragraph"><p>See the "PRETTY FORMATS" section for some additional details for each
 format.  When <em>=&lt;format&gt;</em> part is omitted, it defaults to <em>medium</em>.</p></div>
 <div class="paragraph"><p>Note: you can specify the default pretty format in the repository
 configuration (see <a href="git-config.html">git-config(1)</a>).</p></div>
 </dd>
 <dt class="hdlist1">
 --abbrev-commit
 </dt>
 <dd>
 <p>
         Instead of showing the full 40-byte hexadecimal commit object
         name, show only a partial prefix.  Non default number of
         digits can be specified with "--abbrev=&lt;n&gt;" (which also modifies
         diff output, if it is displayed).
 </p>
 <div class="paragraph"><p>This should make "--pretty=oneline" a whole lot more readable for
 people using 80-column terminals.</p></div>
 </dd>
 <dt class="hdlist1">
 --no-abbrev-commit
 </dt>
 <dd>
 <p>
         Show the full 40-byte hexadecimal commit object name. This negates
         <code>--abbrev-commit</code> and those options which imply it such as
         "--oneline". It also overrides the <code>log.abbrevCommit</code> variable.
 </p>
 </dd>
 <dt class="hdlist1">
 --oneline
 </dt>
 <dd>
 <p>
         This is a shorthand for "--pretty=oneline --abbrev-commit"
         used together.
 </p>
 </dd>
 <dt class="hdlist1">
 --encoding=&lt;encoding&gt;
 </dt>
 <dd>
 <p>
         The commit objects record the encoding used for the log message
         in their encoding header; this option can be used to tell the
         command to re-code the commit log message in the encoding
         preferred by the user.  For non plumbing commands this
         defaults to UTF-8. Note that if an object claims to be encoded
         in <code>X</code> and we are outputting in <code>X</code>, we will output the object
         verbatim; this means that invalid sequences in the original
         commit may be copied to the output.
 </p>
 </dd>
 <dt class="hdlist1">
 --expand-tabs=&lt;n&gt;
 </dt>
 <dt class="hdlist1">
 --expand-tabs
 </dt>
 <dt class="hdlist1">
 --no-expand-tabs
 </dt>
 <dd>
 <p>
         Perform a tab expansion (replace each tab with enough spaces
         to fill to the next display column that is multiple of <em>&lt;n&gt;</em>)
         in the log message before showing it in the output.
         <code>--expand-tabs</code> is a short-hand for <code>--expand-tabs=8</code>, and
         <code>--no-expand-tabs</code> is a short-hand for <code>--expand-tabs=0</code>,
         which disables tab expansion.
 </p>
 <div class="paragraph"><p>By default, tabs are expanded in pretty formats that indent the log
 message by 4 spaces (i.e.  <em>medium</em>, which is the default, <em>full</em>,
 and <em>fuller</em>).</p></div>
 </dd>
 <dt class="hdlist1">
 --notes[=&lt;treeish&gt;]
 </dt>
 <dd>
 <p>
         Show the notes (see <a href="git-notes.html">git-notes(1)</a>) that annotate the
         commit, when showing the commit log message.  This is the default
         for <code>git log</code>, <code>git show</code> and <code>git whatchanged</code> commands when
         there is no <code>--pretty</code>, <code>--format</code>, or <code>--oneline</code> option given
         on the command line.
 </p>
 <div class="paragraph"><p>By default, the notes shown are from the notes refs listed in the
 <code>core.notesRef</code> and <code>notes.displayRef</code> variables (or corresponding
 environment overrides). See <a href="git-config.html">git-config(1)</a> for more details.</p></div>
 <div class="paragraph"><p>With an optional <em>&lt;treeish&gt;</em> argument, use the treeish to find the notes
 to display.  The treeish can specify the full refname when it begins
 with <code>refs/notes/</code>; when it begins with <code>notes/</code>, <code>refs/</code> and otherwise
 <code>refs/notes/</code> is prefixed to form a full name of the ref.</p></div>
 <div class="paragraph"><p>Multiple --notes options can be combined to control which notes are
 being displayed. Examples: "--notes=foo" will show only notes from
 "refs/notes/foo"; "--notes=foo --notes" will show both notes from
 "refs/notes/foo" and from the default notes ref(s).</p></div>
 </dd>
 <dt class="hdlist1">
 --no-notes
 </dt>
 <dd>
 <p>
         Do not show notes. This negates the above <code>--notes</code> option, by
         resetting the list of notes refs from which notes are shown.
         Options are parsed in the order given on the command line, so e.g.
         "--notes --notes=foo --no-notes --notes=bar" will only show notes
         from "refs/notes/bar".
 </p>
 </dd>
 <dt class="hdlist1">
 --show-notes[=&lt;treeish&gt;]
 </dt>
 <dt class="hdlist1">
 --[no-]standard-notes
 </dt>
 <dd>
 <p>
         These options are deprecated. Use the above --notes/--no-notes
         options instead.
 </p>
 </dd>
 <dt class="hdlist1">
 --show-signature
 </dt>
 <dd>
 <p>
         Check the validity of a signed commit object by passing the signature
         to <code>gpg --verify</code> and show the output.
 </p>
 </dd>
 <dt class="hdlist1">
 --relative-date
 </dt>
 <dd>
 <p>
         Synonym for <code>--date=relative</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 --date=&lt;format&gt;
 </dt>
 <dd>
 <p>
         Only takes effect for dates shown in human-readable format, such
         as when using <code>--pretty</code>. <code>log.date</code> config variable sets a default
         value for the log command&#8217;s <code>--date</code> option. By default, dates
         are shown in the original time zone (either committer&#8217;s or
         author&#8217;s). If <code>-local</code> is appended to the format (e.g.,
         <code>iso-local</code>), the user&#8217;s local time zone is used instead.
 </p>
 <div class="paragraph"><p><code>--date=relative</code> shows dates relative to the current time,
 e.g. &#8220;2 hours ago&#8221;. The <code>-local</code> option has no effect for
 <code>--date=relative</code>.</p></div>
 <div class="paragraph"><p><code>--date=local</code> is an alias for <code>--date=default-local</code>.</p></div>
 <div class="paragraph"><p><code>--date=iso</code> (or <code>--date=iso8601</code>) shows timestamps in a ISO 8601-like format.
 The differences to the strict ISO 8601 format are:</p></div>
 <div class="ulist"><ul>
 <li>
 <p>
 a space instead of the <code>T</code> date/time delimiter
 </p>
 </li>
 <li>
 <p>
 a space between time and time zone
 </p>
 </li>
 <li>
 <p>
 no colon between hours and minutes of the time zone
 </p>
 </li>
 </ul></div>
 <div class="paragraph"><p><code>--date=iso-strict</code> (or <code>--date=iso8601-strict</code>) shows timestamps in strict
 ISO 8601 format.</p></div>
 <div class="paragraph"><p><code>--date=rfc</code> (or <code>--date=rfc2822</code>) shows timestamps in RFC 2822
 format, often found in email messages.</p></div>
 <div class="paragraph"><p><code>--date=short</code> shows only the date, but not the time, in <code>YYYY-MM-DD</code> format.</p></div>
 <div class="paragraph"><p><code>--date=raw</code> shows the date as seconds since the epoch (1970-01-01
 00:00:00 UTC), followed by a space, and then the timezone as an offset
 from UTC (a <code>+</code> or <code>-</code> with four digits; the first two are hours, and
 the second two are minutes). I.e., as if the timestamp were formatted
 with <code>strftime("%s %z")</code>).
 Note that the <code>-local</code> option does not affect the seconds-since-epoch
 value (which is always measured in UTC), but does switch the accompanying
 timezone value.</p></div>
 <div class="paragraph"><p><code>--date=unix</code> shows the date as a Unix epoch timestamp (seconds since
 1970).  As with <code>--raw</code>, this is always in UTC and therefore <code>-local</code>
 has no effect.</p></div>
 <div class="paragraph"><p><code>--date=format:...</code> feeds the format <code>...</code> to your system <code>strftime</code>,
 except for %z and %Z, which are handled internally.
 Use <code>--date=format:%c</code> to show the date in your system locale&#8217;s
 preferred format.  See the <code>strftime</code> manual for a complete list of
 format placeholders. When using <code>-local</code>, the correct syntax is
 <code>--date=format-local:...</code>.</p></div>
 <div class="paragraph"><p><code>--date=default</code> is the default format, and is similar to
 <code>--date=rfc2822</code>, with a few exceptions:</p></div>
 <div class="ulist"><ul>
 <li>
 <p>
 there is no comma after the day-of-week
 </p>
 </li>
 <li>
 <p>
 the time zone is omitted when the local time zone is used
 </p>
 </li>
 </ul></div>
 </dd>
 <dt class="hdlist1">
 --parents
 </dt>
 <dd>
 <p>
         Print also the parents of the commit (in the form "commit parent&#8230;").
         Also enables parent rewriting, see <em>History Simplification</em> above.
 </p>
 </dd>
 <dt class="hdlist1">
 --children
 </dt>
 <dd>
 <p>
         Print also the children of the commit (in the form "commit child&#8230;").
         Also enables parent rewriting, see <em>History Simplification</em> above.
 </p>
 </dd>
 <dt class="hdlist1">
 --left-right
 </dt>
 <dd>
 <p>
         Mark which side of a symmetric difference a commit is reachable from.
         Commits from the left side are prefixed with <code>&lt;</code> and those from
         the right with <code>&gt;</code>.  If combined with <code>--boundary</code>, those
         commits are prefixed with <code>-</code>.
 </p>
 <div class="paragraph"><p>For example, if you have this topology:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code>             y---b---b  branch B
             / \ /
            /   .
           /   / \
          o---x---a---a  branch A</code></pre>
 </div></div>
 <div class="paragraph"><p>you would get an output like this:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code>        $ git rev-list --left-right --boundary --pretty=oneline A...B

         &gt;bbbbbbb... 3rd on b
         &gt;bbbbbbb... 2nd on b
         &lt;aaaaaaa... 3rd on a
         &lt;aaaaaaa... 2nd on a
         -yyyyyyy... 1st on b
         -xxxxxxx... 1st on a</code></pre>
 </div></div>
 </dd>
 <dt class="hdlist1">
 --graph
 </dt>
 <dd>
 <p>
         Draw a text-based graphical representation of the commit history
         on the left hand side of the output.  This may cause extra lines
         to be printed in between commits, in order for the graph history
         to be drawn properly.
         Cannot be combined with <code>--no-walk</code>.
 </p>
 <div class="paragraph"><p>This enables parent rewriting, see <em>History Simplification</em> above.</p></div>
 <div class="paragraph"><p>This implies the <code>--topo-order</code> option by default, but the
 <code>--date-order</code> option may also be specified.</p></div>
 </dd>
 <dt class="hdlist1">
 --show-linear-break[=&lt;barrier&gt;]
 </dt>
 <dd>
 <p>
         When --graph is not used, all history branches are flattened
         which can make it hard to see that the two consecutive commits
         do not belong to a linear branch. This option puts a barrier
         in between them in that case. If <code>&lt;barrier&gt;</code> is specified, it
         is the string that will be shown instead of the default one.
 </p>
 </dd>
 </dl></div>
 </div>
 <div class="sect2">
 <h3 id="_diff_formatting">Diff Formatting</h3>
 <div class="paragraph"><p>Listed below are options that control the formatting of diff output.
 Some of them are specific to <a href="git-rev-list.html">git-rev-list(1)</a>, however other diff
 options may be given. See <a href="git-diff-files.html">git-diff-files(1)</a> for more options.</p></div>
 <div class="dlist"><dl>
 <dt class="hdlist1">
 -c
 </dt>
 <dd>
 <p>
         With this option, diff output for a merge commit
         shows the differences from each of the parents to the merge result
         simultaneously instead of showing pairwise diff between a parent
         and the result one at a time. Furthermore, it lists only files
         which were modified from all parents.
 </p>
 </dd>
 <dt class="hdlist1">
 --cc
 </dt>
 <dd>
 <p>
         This flag implies the <code>-c</code> option and further compresses the
         patch output by omitting uninteresting hunks whose contents in
         the parents have only two variants and the merge result picks
         one of them without modification.
 </p>
 </dd>
 <dt class="hdlist1">
 -m
 </dt>
 <dd>
 <p>
         This flag makes the merge commits show the full diff like
         regular commits; for each merge parent, a separate log entry
         and diff is generated. An exception is that only diff against
         the first parent is shown when <code>--first-parent</code> option is given;
         in that case, the output represents the changes the merge
         brought <em>into</em> the then-current branch.
 </p>
 </dd>
 <dt class="hdlist1">
 -r
 </dt>
 <dd>
 <p>
         Show recursive diffs.
 </p>
 </dd>
 <dt class="hdlist1">
 -t
 </dt>
 <dd>
 <p>
         Show the tree objects in the diff output. This implies <code>-r</code>.
 </p>
 </dd>
 </dl></div>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="_pretty_formats">PRETTY FORMATS</h2>
 <div class="sectionbody">
 <div class="paragraph"><p>If the commit is a merge, and if the pretty-format
 is not <em>oneline</em>, <em>email</em> or <em>raw</em>, an additional line is
 inserted before the <em>Author:</em> line.  This line begins with
 "Merge: " and the sha1s of ancestral commits are printed,
 separated by spaces.  Note that the listed commits may not
 necessarily be the list of the <strong>direct</strong> parent commits if you
 have limited your view of history: for example, if you are
 only interested in changes related to a certain directory or
 file.</p></div>
 <div class="paragraph"><p>There are several built-in formats, and you can define
 additional formats by setting a pretty.&lt;name&gt;
 config option to either another format name, or a
 <em>format:</em> string, as described below (see
 <a href="git-config.html">git-config(1)</a>). Here are the details of the
 built-in formats:</p></div>
 <div class="ulist"><ul>
 <li>
 <p>
 <em>oneline</em>
 </p>
 <div class="literalblock">
 <div class="content">
 <pre><code>&lt;sha1&gt; &lt;title line&gt;</code></pre>
 </div></div>
 <div class="paragraph"><p>This is designed to be as compact as possible.</p></div>
 </li>
 <li>
 <p>
 <em>short</em>
 </p>
 <div class="literalblock">
 <div class="content">
 <pre><code>commit &lt;sha1&gt;
 Author: &lt;author&gt;</code></pre>
 </div></div>
 <div class="literalblock">
 <div class="content">
 <pre><code>&lt;title line&gt;</code></pre>
 </div></div>
 </li>
 <li>
 <p>
 <em>medium</em>
 </p>
 <div class="literalblock">
 <div class="content">
 <pre><code>commit &lt;sha1&gt;
 Author: &lt;author&gt;
 Date:   &lt;author date&gt;</code></pre>
 </div></div>
 <div class="literalblock">
 <div class="content">
 <pre><code>&lt;title line&gt;</code></pre>
 </div></div>
 <div class="literalblock">
 <div class="content">
 <pre><code>&lt;full commit message&gt;</code></pre>
 </div></div>
 </li>
 <li>
 <p>
 <em>full</em>
 </p>
 <div class="literalblock">
 <div class="content">
 <pre><code>commit &lt;sha1&gt;
 Author: &lt;author&gt;
 Commit: &lt;committer&gt;</code></pre>
 </div></div>
 <div class="literalblock">
 <div class="content">
 <pre><code>&lt;title line&gt;</code></pre>
 </div></div>
 <div class="literalblock">
 <div class="content">
 <pre><code>&lt;full commit message&gt;</code></pre>
 </div></div>
 </li>
 <li>
 <p>
 <em>fuller</em>
 </p>
 <div class="literalblock">
 <div class="content">
 <pre><code>commit &lt;sha1&gt;
 Author:     &lt;author&gt;
 AuthorDate: &lt;author date&gt;
 Commit:     &lt;committer&gt;
 CommitDate: &lt;committer date&gt;</code></pre>
 </div></div>
 <div class="literalblock">
 <div class="content">
 <pre><code>&lt;title line&gt;</code></pre>
 </div></div>
 <div class="literalblock">
 <div class="content">
 <pre><code>&lt;full commit message&gt;</code></pre>
 </div></div>
 </li>
 <li>
 <p>
 <em>email</em>
 </p>
 <div class="literalblock">
 <div class="content">
 <pre><code>From &lt;sha1&gt; &lt;date&gt;
 From: &lt;author&gt;
 Date: &lt;author date&gt;
 Subject: [PATCH] &lt;title line&gt;</code></pre>
 </div></div>
 <div class="literalblock">
 <div class="content">
 <pre><code>&lt;full commit message&gt;</code></pre>
 </div></div>
 </li>
 <li>
 <p>
 <em>raw</em>
 </p>
 <div class="paragraph"><p>The <em>raw</em> format shows the entire commit exactly as
 stored in the commit object.  Notably, the SHA-1s are
 displayed in full, regardless of whether --abbrev or
 --no-abbrev are used, and <em>parents</em> information show the
 true parent commits, without taking grafts or history
 simplification into account. Note that this format affects the way
 commits are displayed, but not the way the diff is shown e.g. with
 <code>git log --raw</code>. To get full object names in a raw diff format,
 use <code>--no-abbrev</code>.</p></div>
 </li>
 <li>
 <p>
 <em>format:&lt;string&gt;</em>
 </p>
 <div class="paragraph"><p>The <em>format:&lt;string&gt;</em> format allows you to specify which information
 you want to show. It works a little bit like printf format,
 with the notable exception that you get a newline with <em>%n</em>
 instead of <em>\n</em>.</p></div>
 <div class="paragraph"><p>E.g, <em>format:"The author of %h was %an, %ar%nThe title was &gt;&gt;%s&lt;&lt;%n"</em>
 would show something like this:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code>The author of fe6e0ee was Junio C Hamano, 23 hours ago
 The title was &gt;&gt;t4119: test autocomputing -p&lt;n&gt; for traditional diff input.&lt;&lt;</code></pre>
 </div></div>
 <div class="paragraph"><p>The placeholders are:</p></div>
 <div class="ulist"><ul>
 <li>
 <p>
 <em>%H</em>: commit hash
 </p>
 </li>
 <li>
 <p>
 <em>%h</em>: abbreviated commit hash
 </p>
 </li>
 <li>
 <p>
 <em>%T</em>: tree hash
 </p>
 </li>
 <li>
 <p>
 <em>%t</em>: abbreviated tree hash
 </p>
 </li>
 <li>
 <p>
 <em>%P</em>: parent hashes
 </p>
 </li>
 <li>
 <p>
 <em>%p</em>: abbreviated parent hashes
 </p>
 </li>
 <li>
 <p>
 <em>%an</em>: author name
 </p>
 </li>
 <li>
 <p>
 <em>%aN</em>: author name (respecting .mailmap, see <a href="git-shortlog.html">git-shortlog(1)</a>
   or <a href="git-blame.html">git-blame(1)</a>)
 </p>
 </li>
 <li>
 <p>
 <em>%ae</em>: author email
 </p>
 </li>
 <li>
 <p>
 <em>%aE</em>: author email (respecting .mailmap, see
   <a href="git-shortlog.html">git-shortlog(1)</a> or <a href="git-blame.html">git-blame(1)</a>)
 </p>
 </li>
 <li>
 <p>
 <em>%ad</em>: author date (format respects --date= option)
 </p>
 </li>
 <li>
 <p>
 <em>%aD</em>: author date, RFC2822 style
 </p>
 </li>
 <li>
 <p>
 <em>%ar</em>: author date, relative
 </p>
 </li>
 <li>
 <p>
 <em>%at</em>: author date, UNIX timestamp
 </p>
 </li>
 <li>
 <p>
 <em>%ai</em>: author date, ISO 8601-like format
 </p>
 </li>
 <li>
 <p>
 <em>%aI</em>: author date, strict ISO 8601 format
 </p>
 </li>
 <li>
 <p>
 <em>%cn</em>: committer name
 </p>
 </li>
 <li>
 <p>
 <em>%cN</em>: committer name (respecting .mailmap, see
   <a href="git-shortlog.html">git-shortlog(1)</a> or <a href="git-blame.html">git-blame(1)</a>)
 </p>
 </li>
 <li>
 <p>
 <em>%ce</em>: committer email
 </p>
 </li>
 <li>
 <p>
 <em>%cE</em>: committer email (respecting .mailmap, see
   <a href="git-shortlog.html">git-shortlog(1)</a> or <a href="git-blame.html">git-blame(1)</a>)
 </p>
 </li>
 <li>
 <p>
 <em>%cd</em>: committer date (format respects --date= option)
 </p>
 </li>
 <li>
 <p>
 <em>%cD</em>: committer date, RFC2822 style
 </p>
 </li>
 <li>
 <p>
 <em>%cr</em>: committer date, relative
 </p>
 </li>
 <li>
 <p>
 <em>%ct</em>: committer date, UNIX timestamp
 </p>
 </li>
 <li>
 <p>
 <em>%ci</em>: committer date, ISO 8601-like format
 </p>
 </li>
 <li>
 <p>
 <em>%cI</em>: committer date, strict ISO 8601 format
 </p>
 </li>
 <li>
 <p>
 <em>%d</em>: ref names, like the --decorate option of <a href="git-log.html">git-log(1)</a>
 </p>
 </li>
 <li>
 <p>
 <em>%D</em>: ref names without the " (", ")" wrapping.
 </p>
 </li>
 <li>
 <p>
 <em>%e</em>: encoding
 </p>
 </li>
 <li>
 <p>
 <em>%s</em>: subject
 </p>
 </li>
 <li>
 <p>
 <em>%f</em>: sanitized subject line, suitable for a filename
 </p>
 </li>
 <li>
 <p>
 <em>%b</em>: body
 </p>
 </li>
 <li>
 <p>
 <em>%B</em>: raw body (unwrapped subject and body)
 </p>
 </li>
 <li>
 <p>
 <em>%N</em>: commit notes
 </p>
 </li>
 <li>
 <p>
 <em>%GG</em>: raw verification message from GPG for a signed commit
 </p>
 </li>
 <li>
 <p>
 <em>%G?</em>: show "G" for a good (valid) signature,
   "B" for a bad signature,
   "U" for a good signature with unknown validity,
   "X" for a good signature that has expired,
   "Y" for a good signature made by an expired key,
   "R" for a good signature made by a revoked key,
   "E" if the signature cannot be checked (e.g. missing key)
   and "N" for no signature
 </p>
 </li>
 <li>
 <p>
 <em>%GS</em>: show the name of the signer for a signed commit
 </p>
 </li>
 <li>
 <p>
 <em>%GK</em>: show the key used to sign a signed commit
 </p>
 </li>
 <li>
 <p>
 <em>%GF</em>: show the fingerprint of the key used to sign a signed commit
 </p>
 </li>
 <li>
 <p>
 <em>%GP</em>: show the fingerprint of the primary key whose subkey was used
   to sign a signed commit
 </p>
 </li>
 <li>
 <p>
 <em>%gD</em>: reflog selector, e.g., <code>refs/stash@{1}</code> or
   <code>refs/stash@{2 minutes ago</code>}; the format follows the rules described
   for the <code>-g</code> option. The portion before the <code>@</code> is the refname as
   given on the command line (so <code>git log -g refs/heads/master</code> would
   yield <code>refs/heads/master@{0}</code>).
 </p>
 </li>
 <li>
 <p>
 <em>%gd</em>: shortened reflog selector; same as <code>%gD</code>, but the refname
   portion is shortened for human readability (so <code>refs/heads/master</code>
   becomes just <code>master</code>).
 </p>
 </li>
 <li>
 <p>
 <em>%gn</em>: reflog identity name
 </p>
 </li>
 <li>
 <p>
 <em>%gN</em>: reflog identity name (respecting .mailmap, see
   <a href="git-shortlog.html">git-shortlog(1)</a> or <a href="git-blame.html">git-blame(1)</a>)
 </p>
 </li>
 <li>
 <p>
 <em>%ge</em>: reflog identity email
 </p>
 </li>
 <li>
 <p>
 <em>%gE</em>: reflog identity email (respecting .mailmap, see
   <a href="git-shortlog.html">git-shortlog(1)</a> or <a href="git-blame.html">git-blame(1)</a>)
 </p>
 </li>
 <li>
 <p>
 <em>%gs</em>: reflog subject
 </p>
 </li>
 <li>
 <p>
 <em>%Cred</em>: switch color to red
 </p>
 </li>
 <li>
 <p>
 <em>%Cgreen</em>: switch color to green
 </p>
 </li>
 <li>
 <p>
 <em>%Cblue</em>: switch color to blue
 </p>
 </li>
 <li>
 <p>
 <em>%Creset</em>: reset color
 </p>
 </li>
 <li>
 <p>
 <em>%C(&#8230;)</em>: color specification, as described under Values in the
   "CONFIGURATION FILE" section of <a href="git-config.html">git-config(1)</a>.
   By default, colors are shown only when enabled for log output (by
   <code>color.diff</code>, <code>color.ui</code>, or <code>--color</code>, and respecting the <code>auto</code>
   settings of the former if we are going to a terminal). <code>%C(auto,...)</code>
   is accepted as a historical synonym for the default (e.g.,
   <code>%C(auto,red)</code>). Specifying <code>%C(always,...) will show the colors
   even when color is not otherwise enabled (though consider
   just using `--color=always</code> to enable color for the whole output,
   including this format and anything else git might color).  <code>auto</code>
   alone (i.e. <code>%C(auto)</code>) will turn on auto coloring on the next
   placeholders until the color is switched again.
 </p>
 </li>
 <li>
 <p>
 <em>%m</em>: left (<code>&lt;</code>), right (<code>&gt;</code>) or boundary (<code>-</code>) mark
 </p>
 </li>
 <li>
 <p>
 <em>%n</em>: newline
 </p>
 </li>
 <li>
 <p>
 <em>%%</em>: a raw <em>%</em>
 </p>
 </li>
 <li>
 <p>
 <em>%x00</em>: print a byte from a hex code
 </p>
 </li>
 <li>
 <p>
 <em>%w([&lt;w&gt;[,&lt;i1&gt;[,&lt;i2&gt;]]])</em>: switch line wrapping, like the -w option of
   <a href="git-shortlog.html">git-shortlog(1)</a>.
 </p>
 </li>
 <li>
 <p>
 <em>%&lt;(&lt;N&gt;[,trunc|ltrunc|mtrunc])</em>: make the next placeholder take at
   least N columns, padding spaces on the right if necessary.
   Optionally truncate at the beginning (ltrunc), the middle (mtrunc)
   or the end (trunc) if the output is longer than N columns.
   Note that truncating only works correctly with N &gt;= 2.
 </p>
 </li>
 <li>
 <p>
 <em>%&lt;|(&lt;N&gt;)</em>: make the next placeholder take at least until Nth
   columns, padding spaces on the right if necessary
 </p>
 </li>
 <li>
 <p>
 <em>%&gt;(&lt;N&gt;)</em>, <em>%&gt;|(&lt;N&gt;)</em>: similar to <em>%&lt;(&lt;N&gt;)</em>, <em>%&lt;|(&lt;N&gt;)</em>
   respectively, but padding spaces on the left
 </p>
 </li>
 <li>
 <p>
 <em>%&gt;&gt;(&lt;N&gt;)</em>, <em>%&gt;&gt;|(&lt;N&gt;)</em>: similar to <em>%&gt;(&lt;N&gt;)</em>, <em>%&gt;|(&lt;N&gt;)</em>
   respectively, except that if the next placeholder takes more spaces
   than given and there are spaces on its left, use those spaces
 </p>
 </li>
 <li>
 <p>
 <em>%&gt;&lt;(&lt;N&gt;)</em>, <em>%&gt;&lt;|(&lt;N&gt;)</em>: similar to <em>%&lt;(&lt;N&gt;)</em>, <em>%&lt;|(&lt;N&gt;)</em>
   respectively, but padding both sides (i.e. the text is centered)
 </p>
 </li>
 <li>
 <p>
 %(trailers[:options]): display the trailers of the body as interpreted
   by <a href="git-interpret-trailers.html">git-interpret-trailers(1)</a>. The <code>trailers</code> string may be
   followed by a colon and zero or more comma-separated options. If the
   <code>only</code> option is given, omit non-trailer lines from the trailer block.
   If the <code>unfold</code> option is given, behave as if interpret-trailer&#8217;s
   <code>--unfold</code> option was given.  E.g., <code>%(trailers:only,unfold)</code> to do
   both.
 </p>
 </li>
 </ul></div>
 </li>
 </ul></div>
 <div class="admonitionblock">
 <table><tr>
 <td class="icon">
 <div class="title">Note</div>
 </td>
 <td class="content">Some placeholders may depend on other options given to the
 revision traversal engine. For example, the <code>%g*</code> reflog options will
 insert an empty string unless we are traversing reflog entries (e.g., by
 <code>git log -g</code>). The <code>%d</code> and <code>%D</code> placeholders will use the "short"
 decoration format if <code>--decorate</code> was not already provided on the command
 line.</td>
 </tr></table>
 </div>
 <div class="paragraph"><p>If you add a <code>+</code> (plus sign) after <em>%</em> of a placeholder, a line-feed
 is inserted immediately before the expansion if and only if the
 placeholder expands to a non-empty string.</p></div>
 <div class="paragraph"><p>If you add a <code>-</code> (minus sign) after <em>%</em> of a placeholder, all consecutive
 line-feeds immediately preceding the expansion are deleted if and only if the
 placeholder expands to an empty string.</p></div>
 <div class="paragraph"><p>If you add a ` ` (space) after <em>%</em> of a placeholder, a space
 is inserted immediately before the expansion if and only if the
 placeholder expands to a non-empty string.</p></div>
 <div class="ulist"><ul>
 <li>
 <p>
 <em>tformat:</em>
 </p>
 <div class="paragraph"><p>The <em>tformat:</em> format works exactly like <em>format:</em>, except that it
 provides "terminator" semantics instead of "separator" semantics. In
 other words, each commit has the message terminator character (usually a
 newline) appended, rather than a separator placed between entries.
 This means that the final entry of a single-line format will be properly
 terminated with a new line, just as the "oneline" format does.
 For example:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code>$ git log -2 --pretty=format:%h 4da45bef \
   | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
 4da45be
 7134973 -- NO NEWLINE

 $ git log -2 --pretty=tformat:%h 4da45bef \
   | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
 4da45be
 7134973</code></pre>
 </div></div>
 <div class="paragraph"><p>In addition, any unrecognized string that has a <code>%</code> in it is interpreted
 as if it has <code>tformat:</code> in front of it.  For example, these two are
 equivalent:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code>$ git log -2 --pretty=tformat:%h 4da45bef
 $ git log -2 --pretty=%h 4da45bef</code></pre>
 </div></div>
 </li>
 </ul></div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="_common_diff_options">COMMON DIFF OPTIONS</h2>
 <div class="sectionbody">
 <div class="dlist"><dl>
 <dt class="hdlist1">
 -p
 </dt>
 <dt class="hdlist1">
 -u
 </dt>
 <dt class="hdlist1">
 --patch
 </dt>
 <dd>
 <p>
         Generate patch (see section on generating patches).
 </p>
 </dd>
 <dt class="hdlist1">
 -s
 </dt>
 <dt class="hdlist1">
 --no-patch
 </dt>
 <dd>
 <p>
         Suppress diff output. Useful for commands like <code>git show</code> that
         show the patch by default, or to cancel the effect of <code>--patch</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 -U&lt;n&gt;
 </dt>
 <dt class="hdlist1">
 --unified=&lt;n&gt;
 </dt>
 <dd>
 <p>
         Generate diffs with &lt;n&gt; lines of context instead of
         the usual three.
         Implies <code>-p</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 --raw
 </dt>
 <dd>
 <p>
         For each commit, show a summary of changes using the raw diff
         format. See the "RAW OUTPUT FORMAT" section of
         <a href="git-diff.html">git-diff(1)</a>. This is different from showing the log
         itself in raw format, which you can achieve with
         <code>--format=raw</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 --patch-with-raw
 </dt>
 <dd>
 <p>
         Synonym for <code>-p --raw</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 --indent-heuristic
 </dt>
 <dd>
 <p>
         Enable the heuristic that shifts diff hunk boundaries to make patches
         easier to read. This is the default.
 </p>
 </dd>
 <dt class="hdlist1">
 --no-indent-heuristic
 </dt>
 <dd>
 <p>
         Disable the indent heuristic.
 </p>
 </dd>
 <dt class="hdlist1">
 --minimal
 </dt>
 <dd>
 <p>
         Spend extra time to make sure the smallest possible
         diff is produced.
 </p>
 </dd>
 <dt class="hdlist1">
 --patience
 </dt>
 <dd>
 <p>
         Generate a diff using the "patience diff" algorithm.
 </p>
 </dd>
 <dt class="hdlist1">
 --histogram
 </dt>
 <dd>
 <p>
         Generate a diff using the "histogram diff" algorithm.
 </p>
 </dd>
 <dt class="hdlist1">
 --anchored=&lt;text&gt;
 </dt>
 <dd>
 <p>
         Generate a diff using the "anchored diff" algorithm.
 </p>
 <div class="paragraph"><p>This option may be specified more than once.</p></div>
 <div class="paragraph"><p>If a line exists in both the source and destination, exists only once,
 and starts with this text, this algorithm attempts to prevent it from
 appearing as a deletion or addition in the output. It uses the "patience
 diff" algorithm internally.</p></div>
 </dd>
 <dt class="hdlist1">
 --diff-algorithm={patience|minimal|histogram|myers}
 </dt>
 <dd>
 <p>
         Choose a diff algorithm. The variants are as follows:
 </p>
 <div class="openblock">
 <div class="content">
 <div class="dlist"><dl>
 <dt class="hdlist1">
 <code>default</code>, <code>myers</code>
 </dt>
 <dd>
 <p>
         The basic greedy diff algorithm. Currently, this is the default.
 </p>
 </dd>
 <dt class="hdlist1">
 <code>minimal</code>
 </dt>
 <dd>
 <p>
         Spend extra time to make sure the smallest possible diff is
         produced.
 </p>
 </dd>
 <dt class="hdlist1">
 <code>patience</code>
 </dt>
 <dd>
 <p>
         Use "patience diff" algorithm when generating patches.
 </p>
 </dd>
 <dt class="hdlist1">
 <code>histogram</code>
 </dt>
 <dd>
 <p>
         This algorithm extends the patience algorithm to "support
         low-occurrence common elements".
 </p>
 </dd>
 </dl></div>
 </div></div>
 <div class="paragraph"><p>For instance, if you configured the <code>diff.algorithm</code> variable to a
 non-default value and want to use the default one, then you
 have to use <code>--diff-algorithm=default</code> option.</p></div>
 </dd>
 <dt class="hdlist1">
 --stat[=&lt;width&gt;[,&lt;name-width&gt;[,&lt;count&gt;]]]
 </dt>
 <dd>
 <p>
         Generate a diffstat. By default, as much space as necessary
         will be used for the filename part, and the rest for the graph
         part. Maximum width defaults to terminal width, or 80 columns
         if not connected to a terminal, and can be overridden by
         <code>&lt;width&gt;</code>. The width of the filename part can be limited by
         giving another width <code>&lt;name-width&gt;</code> after a comma. The width
         of the graph part can be limited by using
         <code>--stat-graph-width=&lt;width&gt;</code> (affects all commands generating
         a stat graph) or by setting <code>diff.statGraphWidth=&lt;width&gt;</code>
         (does not affect <code>git format-patch</code>).
         By giving a third parameter <code>&lt;count&gt;</code>, you can limit the
         output to the first <code>&lt;count&gt;</code> lines, followed by <code>...</code> if
         there are more.
 </p>
 <div class="paragraph"><p>These parameters can also be set individually with <code>--stat-width=&lt;width&gt;</code>,
 <code>--stat-name-width=&lt;name-width&gt;</code> and <code>--stat-count=&lt;count&gt;</code>.</p></div>
 </dd>
 <dt class="hdlist1">
 --compact-summary
 </dt>
 <dd>
 <p>
         Output a condensed summary of extended header information such
         as file creations or deletions ("new" or "gone", optionally "+l"
         if it&#8217;s a symlink) and mode changes ("+x" or "-x" for adding
         or removing executable bit respectively) in diffstat. The
         information is put between the filename part and the graph
         part. Implies <code>--stat</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 --numstat
 </dt>
 <dd>
 <p>
         Similar to <code>--stat</code>, but shows number of added and
         deleted lines in decimal notation and pathname without
         abbreviation, to make it more machine friendly.  For
         binary files, outputs two <code>-</code> instead of saying
         <code>0 0</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 --shortstat
 </dt>
 <dd>
 <p>
         Output only the last line of the <code>--stat</code> format containing total
         number of modified files, as well as number of added and deleted
         lines.
 </p>
 </dd>
 <dt class="hdlist1">
 --dirstat[=&lt;param1,param2,&#8230;&gt;]
 </dt>
 <dd>
 <p>
         Output the distribution of relative amount of changes for each
         sub-directory. The behavior of <code>--dirstat</code> can be customized by
         passing it a comma separated list of parameters.
         The defaults are controlled by the <code>diff.dirstat</code> configuration
         variable (see <a href="git-config.html">git-config(1)</a>).
         The following parameters are available:
 </p>
 <div class="openblock">
 <div class="content">
 <div class="dlist"><dl>
 <dt class="hdlist1">
 <code>changes</code>
 </dt>
 <dd>
 <p>
         Compute the dirstat numbers by counting the lines that have been
         removed from the source, or added to the destination. This ignores
         the amount of pure code movements within a file.  In other words,
         rearranging lines in a file is not counted as much as other changes.
         This is the default behavior when no parameter is given.
 </p>
 </dd>
 <dt class="hdlist1">
 <code>lines</code>
 </dt>
 <dd>
 <p>
         Compute the dirstat numbers by doing the regular line-based diff
         analysis, and summing the removed/added line counts. (For binary
         files, count 64-byte chunks instead, since binary files have no
         natural concept of lines). This is a more expensive <code>--dirstat</code>
         behavior than the <code>changes</code> behavior, but it does count rearranged
         lines within a file as much as other changes. The resulting output
         is consistent with what you get from the other <code>--*stat</code> options.
 </p>
 </dd>
 <dt class="hdlist1">
 <code>files</code>
 </dt>
 <dd>
 <p>
         Compute the dirstat numbers by counting the number of files changed.
         Each changed file counts equally in the dirstat analysis. This is
         the computationally cheapest <code>--dirstat</code> behavior, since it does
         not have to look at the file contents at all.
 </p>
 </dd>
 <dt class="hdlist1">
 <code>cumulative</code>
 </dt>
 <dd>
 <p>
         Count changes in a child directory for the parent directory as well.
         Note that when using <code>cumulative</code>, the sum of the percentages
         reported may exceed 100%. The default (non-cumulative) behavior can
         be specified with the <code>noncumulative</code> parameter.
 </p>
 </dd>
 <dt class="hdlist1">
 &lt;limit&gt;
 </dt>
 <dd>
 <p>
         An integer parameter specifies a cut-off percent (3% by default).
         Directories contributing less than this percentage of the changes
         are not shown in the output.
 </p>
 </dd>
 </dl></div>
 </div></div>
 <div class="paragraph"><p>Example: The following will count changed files, while ignoring
 directories with less than 10% of the total amount of changed files,
 and accumulating child directory counts in the parent directories:
 <code>--dirstat=files,10,cumulative</code>.</p></div>
 </dd>
 <dt class="hdlist1">
 --summary
 </dt>
 <dd>
 <p>
         Output a condensed summary of extended header information
         such as creations, renames and mode changes.
 </p>
 </dd>
 <dt class="hdlist1">
 --patch-with-stat
 </dt>
 <dd>
 <p>
         Synonym for <code>-p --stat</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 -z
 </dt>
 <dd>
 <p>
         Separate the commits with NULs instead of with new newlines.
 </p>
 <div class="paragraph"><p>Also, when <code>--raw</code> or <code>--numstat</code> has been given, do not munge
 pathnames and use NULs as output field terminators.</p></div>
 <div class="paragraph"><p>Without this option, pathnames 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></div>
 </dd>
 <dt class="hdlist1">
 --name-only
 </dt>
 <dd>
 <p>
         Show only names of changed files.
 </p>
 </dd>
 <dt class="hdlist1">
 --name-status
 </dt>
 <dd>
 <p>
         Show only names and status of changed files. See the description
         of the <code>--diff-filter</code> option on what the status letters mean.
 </p>
 </dd>
 <dt class="hdlist1">
 --submodule[=&lt;format&gt;]
 </dt>
 <dd>
 <p>
         Specify how differences in submodules are shown.  When specifying
         <code>--submodule=short</code> the <em>short</em> format is used.  This format just
         shows the names of the commits at the beginning and end of the range.
         When <code>--submodule</code> or <code>--submodule=log</code> is specified, the <em>log</em>
         format is used.  This format lists the commits in the range like
         <a href="git-submodule.html">git-submodule(1)</a> <code>summary</code> does.  When <code>--submodule=diff</code>
         is specified, the <em>diff</em> format is used.  This format shows an
         inline diff of the changes in the submodule contents between the
         commit range.  Defaults to <code>diff.submodule</code> or the <em>short</em> format
         if the config option is unset.
 </p>
 </dd>
 <dt class="hdlist1">
 --color[=&lt;when&gt;]
 </dt>
 <dd>
 <p>
         Show colored diff.
         <code>--color</code> (i.e. without <em>=&lt;when&gt;</em>) is the same as <code>--color=always</code>.
         <em>&lt;when&gt;</em> can be one of <code>always</code>, <code>never</code>, or <code>auto</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 --no-color
 </dt>
 <dd>
 <p>
         Turn off colored diff.
         It is the same as <code>--color=never</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 --color-moved[=&lt;mode&gt;]
 </dt>
 <dd>
 <p>
         Moved lines of code are colored differently.
         The &lt;mode&gt; defaults to <em>no</em> if the option is not given
         and to <em>zebra</em> if the option with no mode is given.
         The mode must be one of:
 </p>
 <div class="openblock">
 <div class="content">
 <div class="dlist"><dl>
 <dt class="hdlist1">
 no
 </dt>
 <dd>
 <p>
         Moved lines are not highlighted.
 </p>
 </dd>
 <dt class="hdlist1">
 default
 </dt>
 <dd>
 <p>
         Is a synonym for <code>zebra</code>. This may change to a more sensible mode
         in the future.
 </p>
 </dd>
 <dt class="hdlist1">
 plain
 </dt>
 <dd>
 <p>
         Any line that is added in one location and was removed
         in another location will be colored with <em>color.diff.newMoved</em>.
         Similarly <em>color.diff.oldMoved</em> will be used for removed lines
         that are added somewhere else in the diff. This mode picks up any
         moved line, but it is not very useful in a review to determine
         if a block of code was moved without permutation.
 </p>
 </dd>
 <dt class="hdlist1">
 blocks
 </dt>
 <dd>
 <p>
         Blocks of moved text of at least 20 alphanumeric characters
         are detected greedily. The detected blocks are
         painted using either the <em>color.diff.{old,new}Moved</em> color.
         Adjacent blocks cannot be told apart.
 </p>
 </dd>
 <dt class="hdlist1">
 zebra
 </dt>
 <dd>
 <p>
         Blocks of moved text are detected as in <em>blocks</em> mode. The blocks
         are painted using either the <em>color.diff.{old,new}Moved</em> color or
         <em>color.diff.{old,new}MovedAlternative</em>. The change between
         the two colors indicates that a new block was detected.
 </p>
 </dd>
 <dt class="hdlist1">
 dimmed-zebra
 </dt>
 <dd>
 <p>
         Similar to <em>zebra</em>, but additional dimming of uninteresting parts
         of moved code is performed. The bordering lines of two adjacent
         blocks are considered interesting, the rest is uninteresting.
         <code>dimmed_zebra</code> is a deprecated synonym.
 </p>
 </dd>
 </dl></div>
 </div></div>
 </dd>
 <dt class="hdlist1">
 --color-moved-ws=&lt;modes&gt;
 </dt>
 <dd>
 <p>
         This configures how white spaces are ignored when performing the
         move detection for <code>--color-moved</code>.
         These modes can be given as a comma separated list:
 </p>
 <div class="openblock">
 <div class="content">
 <div class="dlist"><dl>
 <dt class="hdlist1">
 ignore-space-at-eol
 </dt>
 <dd>
 <p>
         Ignore changes in whitespace at EOL.
 </p>
 </dd>
 <dt class="hdlist1">
 ignore-space-change
 </dt>
 <dd>
 <p>
         Ignore changes in amount of whitespace.  This ignores whitespace
         at line end, and considers all other sequences of one or
         more whitespace characters to be equivalent.
 </p>
 </dd>
 <dt class="hdlist1">
 ignore-all-space
 </dt>
 <dd>
 <p>
         Ignore whitespace when comparing lines. This ignores differences
         even if one line has whitespace where the other line has none.
 </p>
 </dd>
 <dt class="hdlist1">
 allow-indentation-change
 </dt>
 <dd>
 <p>
         Initially ignore any white spaces in the move detection, then
         group the moved code blocks only into a block if the change in
         whitespace is the same per line. This is incompatible with the
         other modes.
 </p>
 </dd>
 </dl></div>
 </div></div>
 </dd>
 <dt class="hdlist1">
 --word-diff[=&lt;mode&gt;]
 </dt>
 <dd>
 <p>
         Show a word diff, using the &lt;mode&gt; to delimit changed words.
         By default, words are delimited by whitespace; see
         <code>--word-diff-regex</code> below.  The &lt;mode&gt; defaults to <em>plain</em>, and
         must be one of:
 </p>
 <div class="openblock">
 <div class="content">
 <div class="dlist"><dl>
 <dt class="hdlist1">
 color
 </dt>
 <dd>
 <p>
         Highlight changed words using only colors.  Implies <code>--color</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 plain
 </dt>
 <dd>
 <p>
         Show words as <code>[-removed-]</code> and <code>{+added+}</code>.  Makes no
         attempts to escape the delimiters if they appear in the input,
         so the output may be ambiguous.
 </p>
 </dd>
 <dt class="hdlist1">
 porcelain
 </dt>
 <dd>
 <p>
         Use a special line-based format intended for script
         consumption.  Added/removed/unchanged runs are printed in the
         usual unified diff format, starting with a <code>+</code>/<code>-</code>/` `
         character at the beginning of the line and extending to the
         end of the line.  Newlines in the input are represented by a
         tilde <code>~</code> on a line of its own.
 </p>
 </dd>
 <dt class="hdlist1">
 none
 </dt>
 <dd>
 <p>
         Disable word diff again.
 </p>
 </dd>
 </dl></div>
 </div></div>
 <div class="paragraph"><p>Note that despite the name of the first mode, color is used to
 highlight the changed parts in all modes if enabled.</p></div>
 </dd>
 <dt class="hdlist1">
 --word-diff-regex=&lt;regex&gt;
 </dt>
 <dd>
 <p>
         Use &lt;regex&gt; to decide what a word is, instead of considering
         runs of non-whitespace to be a word.  Also implies
         <code>--word-diff</code> unless it was already enabled.
 </p>
 <div class="paragraph"><p>Every non-overlapping match of the
 &lt;regex&gt; is considered a word.  Anything between these matches is
 considered whitespace and ignored(!) for the purposes of finding
 differences.  You may want to append <code>|[^[:space:]]</code> to your regular
 expression to make sure that it matches all non-whitespace characters.
 A match that contains a newline is silently truncated(!) at the
 newline.</p></div>
 <div class="paragraph"><p>For example, <code>--word-diff-regex=.</code> will treat each character as a word
 and, correspondingly, show differences character by character.</p></div>
 <div class="paragraph"><p>The regex can also be set via a diff driver or configuration option, see
 <a href="gitattributes.html">gitattributes(5)</a> or <a href="git-config.html">git-config(1)</a>.  Giving it explicitly
 overrides any diff driver or configuration setting.  Diff drivers
 override configuration settings.</p></div>
 </dd>
 <dt class="hdlist1">
 --color-words[=&lt;regex&gt;]
 </dt>
 <dd>
 <p>
         Equivalent to <code>--word-diff=color</code> plus (if a regex was
         specified) <code>--word-diff-regex=&lt;regex&gt;</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 --no-renames
 </dt>
 <dd>
 <p>
         Turn off rename detection, even when the configuration
         file gives the default to do so.
 </p>
 </dd>
 <dt class="hdlist1">
 --check
 </dt>
 <dd>
 <p>
         Warn if changes introduce conflict markers or whitespace errors.
         What are considered whitespace errors is controlled by <code>core.whitespace</code>
         configuration.  By default, trailing whitespaces (including
         lines that consist solely of whitespaces) and a space character
         that is immediately followed by a tab character inside the
         initial indent of the line are considered whitespace errors.
         Exits with non-zero status if problems are found. Not compatible
         with --exit-code.
 </p>
 </dd>
 <dt class="hdlist1">
 --ws-error-highlight=&lt;kind&gt;
 </dt>
 <dd>
 <p>
         Highlight whitespace errors in the <code>context</code>, <code>old</code> or <code>new</code>
         lines of the diff.  Multiple values are separated by comma,
         <code>none</code> resets previous values, <code>default</code> reset the list to
         <code>new</code> and <code>all</code> is a shorthand for <code>old,new,context</code>.  When
         this option is not given, and the configuration variable
         <code>diff.wsErrorHighlight</code> is not set, only whitespace errors in
         <code>new</code> lines are highlighted. The whitespace errors are colored
         with <code>color.diff.whitespace</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 --full-index
 </dt>
 <dd>
 <p>
         Instead of the first handful of characters, show the full
         pre- and post-image blob object names on the "index"
         line when generating patch format output.
 </p>
 </dd>
 <dt class="hdlist1">
 --binary
 </dt>
 <dd>
 <p>
         In addition to <code>--full-index</code>, output a binary diff that
         can be applied with <code>git-apply</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 --abbrev[=&lt;n&gt;]
 </dt>
 <dd>
 <p>
         Instead of showing the full 40-byte hexadecimal object
         name in diff-raw format output and diff-tree header
         lines, show only a partial prefix.  This is
         independent of the <code>--full-index</code> option above, which controls
         the diff-patch output format.  Non default number of
         digits can be specified with <code>--abbrev=&lt;n&gt;</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 -B[&lt;n&gt;][/&lt;m&gt;]
 </dt>
 <dt class="hdlist1">
 --break-rewrites[=[&lt;n&gt;][/&lt;m&gt;]]
 </dt>
 <dd>
 <p>
         Break complete rewrite changes into pairs of delete and
         create. This serves two purposes:
 </p>
 <div class="paragraph"><p>It affects the way a change that amounts to a total rewrite of a file
 not as a series of deletion and insertion mixed together with a very
 few lines that happen to match textually as the context, but as a
 single deletion of everything old followed by a single insertion of
 everything new, and the number <code>m</code> controls this aspect of the -B
 option (defaults to 60%). <code>-B/70%</code> specifies that less than 30% of the
 original should remain in the result for Git to consider it a total
 rewrite (i.e. otherwise the resulting patch will be a series of
 deletion and insertion mixed together with context lines).</p></div>
 <div class="paragraph"><p>When used with -M, a totally-rewritten file is also considered as the
 source of a rename (usually -M only considers a file that disappeared
 as the source of a rename), and the number <code>n</code> controls this aspect of
 the -B option (defaults to 50%). <code>-B20%</code> specifies that a change with
 addition and deletion compared to 20% or more of the file&#8217;s size are
 eligible for being picked up as a possible source of a rename to
 another file.</p></div>
 </dd>
 <dt class="hdlist1">
 -M[&lt;n&gt;]
 </dt>
 <dt class="hdlist1">
 --find-renames[=&lt;n&gt;]
 </dt>
 <dd>
 <p>
         If generating diffs, detect and report renames for each commit.
         For following files across renames while traversing history, see
         <code>--follow</code>.
         If <code>n</code> is specified, it is a threshold on the similarity
         index (i.e. amount of addition/deletions compared to the
         file&#8217;s size). For example, <code>-M90%</code> means Git should consider a
         delete/add pair to be a rename if more than 90% of the file
         hasn&#8217;t changed.  Without a <code>%</code> sign, the number is to be read as
         a fraction, with a decimal point before it.  I.e., <code>-M5</code> becomes
         0.5, and is thus the same as <code>-M50%</code>.  Similarly, <code>-M05</code> is
         the same as <code>-M5%</code>.  To limit detection to exact renames, use
         <code>-M100%</code>.  The default similarity index is 50%.
 </p>
 </dd>
 <dt class="hdlist1">
 -C[&lt;n&gt;]
 </dt>
 <dt class="hdlist1">
 --find-copies[=&lt;n&gt;]
 </dt>
 <dd>
 <p>
         Detect copies as well as renames.  See also <code>--find-copies-harder</code>.
         If <code>n</code> is specified, it has the same meaning as for <code>-M&lt;n&gt;</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 --find-copies-harder
 </dt>
 <dd>
 <p>
         For performance reasons, by default, <code>-C</code> option finds copies only
         if the original file of the copy was modified in the same
         changeset.  This flag makes the command
         inspect unmodified files as candidates for the source of
         copy.  This is a very expensive operation for large
         projects, so use it with caution.  Giving more than one
         <code>-C</code> option has the same effect.
 </p>
 </dd>
 <dt class="hdlist1">
 -D
 </dt>
 <dt class="hdlist1">
 --irreversible-delete
 </dt>
 <dd>
 <p>
         Omit the preimage for deletes, i.e. print only the header but not
         the diff between the preimage and <code>/dev/null</code>. The resulting patch
         is not meant to be applied with <code>patch</code> or <code>git apply</code>; this is
         solely for people who want to just concentrate on reviewing the
         text after the change. In addition, the output obviously lacks
         enough information to apply such a patch in reverse, even manually,
         hence the name of the option.
 </p>
 <div class="paragraph"><p>When used together with <code>-B</code>, omit also the preimage in the deletion part
 of a delete/create pair.</p></div>
 </dd>
 <dt class="hdlist1">
 -l&lt;num&gt;
 </dt>
 <dd>
 <p>
         The <code>-M</code> and <code>-C</code> options require O(n^2) processing time where n
         is the number of potential rename/copy targets.  This
         option prevents rename/copy detection from running if
         the number of rename/copy targets exceeds the specified
         number.
 </p>
 </dd>
 <dt class="hdlist1">
 --diff-filter=[(A|C|D|M|R|T|U|X|B)&#8230;[*]]
 </dt>
 <dd>
 <p>
         Select only files that are Added (<code>A</code>), Copied (<code>C</code>),
         Deleted (<code>D</code>), Modified (<code>M</code>), Renamed (<code>R</code>), have their
         type (i.e. regular file, symlink, submodule, &#8230;) changed (<code>T</code>),
         are Unmerged (<code>U</code>), are
         Unknown (<code>X</code>), or have had their pairing Broken (<code>B</code>).
         Any combination of the filter characters (including none) can be used.
         When <code>*</code> (All-or-none) is added to the combination, all
         paths are selected if there is any file that matches
         other criteria in the comparison; if there is no file
         that matches other criteria, nothing is selected.
 </p>
 <div class="paragraph"><p>Also, these upper-case letters can be downcased to exclude.  E.g.
 <code>--diff-filter=ad</code> excludes added and deleted paths.</p></div>
 <div class="paragraph"><p>Note that not all diffs can feature all types. For instance, diffs
 from the index to the working tree can never have Added entries
 (because the set of paths included in the diff is limited by what is in
 the index).  Similarly, copied and renamed entries cannot appear if
 detection for those types is disabled.</p></div>
 </dd>
 <dt class="hdlist1">
 -S&lt;string&gt;
 </dt>
 <dd>
 <p>
         Look for differences that change the number of occurrences of
         the specified string (i.e. addition/deletion) in a file.
         Intended for the scripter&#8217;s use.
 </p>
 <div class="paragraph"><p>It is useful when you&#8217;re looking for an exact block of code (like a
 struct), and want to know the history of that block since it first
 came into being: use the feature iteratively to feed the interesting
 block in the preimage back into <code>-S</code>, and keep going until you get the
 very first version of the block.</p></div>
 </dd>
 <dt class="hdlist1">
 -G&lt;regex&gt;
 </dt>
 <dd>
 <p>
         Look for differences whose patch text contains added/removed
         lines that match &lt;regex&gt;.
 </p>
 <div class="paragraph"><p>To illustrate the difference between <code>-S&lt;regex&gt; --pickaxe-regex</code> and
 <code>-G&lt;regex&gt;</code>, consider a commit with the following diff in the same
 file:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code>+    return !regexec(regexp, two-&gt;ptr, 1, &amp;regmatch, 0);
 ...
 -    hit = !regexec(regexp, mf2.ptr, 1, &amp;regmatch, 0);</code></pre>
 </div></div>
 <div class="paragraph"><p>While <code>git log -G"regexec\(regexp"</code> will show this commit, <code>git log
 -S"regexec\(regexp" --pickaxe-regex</code> will not (because the number of
 occurrences of that string did not change).</p></div>
 <div class="paragraph"><p>See the <em>pickaxe</em> entry in <a href="gitdiffcore.html">gitdiffcore(7)</a> for more
 information.</p></div>
 </dd>
 <dt class="hdlist1">
 --find-object=&lt;object-id&gt;
 </dt>
 <dd>
 <p>
         Look for differences that change the number of occurrences of
         the specified object. Similar to <code>-S</code>, just the argument is different
         in that it doesn&#8217;t search for a specific string but for a specific
         object id.
 </p>
 <div class="paragraph"><p>The object can be a blob or a submodule commit. It implies the <code>-t</code> option in
 <code>git-log</code> to also find trees.</p></div>
 </dd>
 <dt class="hdlist1">
 --pickaxe-all
 </dt>
 <dd>
 <p>
         When <code>-S</code> or <code>-G</code> finds a change, show all the changes in that
         changeset, not just the files that contain the change
         in &lt;string&gt;.
 </p>
 </dd>
 <dt class="hdlist1">
 --pickaxe-regex
 </dt>
 <dd>
 <p>
         Treat the &lt;string&gt; given to <code>-S</code> as an extended POSIX regular
         expression to match.
 </p>
 </dd>
 <dt class="hdlist1">
 -O&lt;orderfile&gt;
 </dt>
 <dd>
 <p>
         Control the order in which files appear in the output.
         This overrides the <code>diff.orderFile</code> configuration variable
         (see <a href="git-config.html">git-config(1)</a>).  To cancel <code>diff.orderFile</code>,
         use <code>-O/dev/null</code>.
 </p>
 <div class="paragraph"><p>The output order is determined by the order of glob patterns in
 &lt;orderfile&gt;.
 All files with pathnames that match the first pattern are output
 first, all files with pathnames that match the second pattern (but not
 the first) are output next, and so on.
 All files with pathnames that do not match any pattern are output
 last, as if there was an implicit match-all pattern at the end of the
 file.
 If multiple pathnames have the same rank (they match the same pattern
 but no earlier patterns), their output order relative to each other is
 the normal order.</p></div>
 <div class="paragraph"><p>&lt;orderfile&gt; is parsed as follows:</p></div>
 <div class="openblock">
 <div class="content">
 <div class="ulist"><ul>
 <li>
 <p>
 Blank lines are ignored, so they can be used as separators for
    readability.
 </p>
 </li>
 <li>
 <p>
 Lines starting with a hash ("<code>#</code>") are ignored, so they can be used
    for comments.  Add a backslash ("<code>\</code>") to the beginning of the
    pattern if it starts with a hash.
 </p>
 </li>
 <li>
 <p>
 Each other line contains a single pattern.
 </p>
 </li>
 </ul></div>
 </div></div>
 <div class="paragraph"><p>Patterns have the same syntax and semantics as patterns used for
 fnmatch(3) without the FNM_PATHNAME flag, except a pathname also
 matches a pattern if removing any number of the final pathname
 components matches the pattern.  For example, the pattern "<code>foo*bar</code>"
 matches "<code>fooasdfbar</code>" and "<code>foo/bar/baz/asdf</code>" but not "<code>foobarx</code>".</p></div>
 </dd>
 <dt class="hdlist1">
 -R
 </dt>
 <dd>
 <p>
         Swap two inputs; that is, show differences from index or
         on-disk file to tree contents.
 </p>
 </dd>
 <dt class="hdlist1">
 --relative[=&lt;path&gt;]
 </dt>
 <dd>
 <p>
         When run from a subdirectory of the project, it can be
         told to exclude changes outside the directory and show
         pathnames relative to it with this option.  When you are
         not in a subdirectory (e.g. in a bare repository), you
         can name which subdirectory to make the output relative
         to by giving a &lt;path&gt; as an argument.
 </p>
 </dd>
 <dt class="hdlist1">
 -a
 </dt>
 <dt class="hdlist1">
 --text
 </dt>
 <dd>
 <p>
         Treat all files as text.
 </p>
 </dd>
 <dt class="hdlist1">
 --ignore-cr-at-eol
 </dt>
 <dd>
 <p>
         Ignore carriage-return at the end of line when doing a comparison.
 </p>
 </dd>
 <dt class="hdlist1">
 --ignore-space-at-eol
 </dt>
 <dd>
 <p>
         Ignore changes in whitespace at EOL.
 </p>
 </dd>
 <dt class="hdlist1">
 -b
 </dt>
 <dt class="hdlist1">
 --ignore-space-change
 </dt>
 <dd>
 <p>
         Ignore changes in amount of whitespace.  This ignores whitespace
         at line end, and considers all other sequences of one or
         more whitespace characters to be equivalent.
 </p>
 </dd>
 <dt class="hdlist1">
 -w
 </dt>
 <dt class="hdlist1">
 --ignore-all-space
 </dt>
 <dd>
 <p>
         Ignore whitespace when comparing lines.  This ignores
         differences even if one line has whitespace where the other
         line has none.
 </p>
 </dd>
 <dt class="hdlist1">
 --ignore-blank-lines
 </dt>
 <dd>
 <p>
         Ignore changes whose lines are all blank.
 </p>
 </dd>
 <dt class="hdlist1">
 --inter-hunk-context=&lt;lines&gt;
 </dt>
 <dd>
 <p>
         Show the context between diff hunks, up to the specified number
         of lines, thereby fusing hunks that are close to each other.
         Defaults to <code>diff.interHunkContext</code> or 0 if the config option
         is unset.
 </p>
 </dd>
 <dt class="hdlist1">
 -W
 </dt>
 <dt class="hdlist1">
 --function-context
 </dt>
 <dd>
 <p>
         Show whole surrounding functions of changes.
 </p>
 </dd>
 <dt class="hdlist1">
 --ext-diff
 </dt>
 <dd>
 <p>
         Allow an external diff helper to be executed. If you set an
         external diff driver with <a href="gitattributes.html">gitattributes(5)</a>, you need
         to use this option with <a href="git-log.html">git-log(1)</a> and friends.
 </p>
 </dd>
 <dt class="hdlist1">
 --no-ext-diff
 </dt>
 <dd>
 <p>
         Disallow external diff drivers.
 </p>
 </dd>
 <dt class="hdlist1">
 --textconv
 </dt>
 <dt class="hdlist1">
 --no-textconv
 </dt>
 <dd>
 <p>
         Allow (or disallow) external text conversion filters to be run
         when comparing binary files. See <a href="gitattributes.html">gitattributes(5)</a> for
         details. Because textconv filters are typically a one-way
         conversion, the resulting diff is suitable for human
         consumption, but cannot be applied. For this reason, textconv
         filters are enabled by default only for <a href="git-diff.html">git-diff(1)</a> and
         <a href="git-log.html">git-log(1)</a>, but not for <a href="git-format-patch.html">git-format-patch(1)</a> or
         diff plumbing commands.
 </p>
 </dd>
 <dt class="hdlist1">
 --ignore-submodules[=&lt;when&gt;]
 </dt>
 <dd>
 <p>
         Ignore changes to submodules in the diff generation. &lt;when&gt; can be
         either "none", "untracked", "dirty" or "all", which is the default.
         Using "none" will consider the submodule modified when it either contains
         untracked or modified files or its HEAD differs from the commit recorded
         in the superproject and can be used to override any settings of the
         <em>ignore</em> option in <a href="git-config.html">git-config(1)</a> or <a href="gitmodules.html">gitmodules(5)</a>. When
         "untracked" is used submodules are not considered dirty when they only
         contain untracked content (but they are still scanned for modified
         content). Using "dirty" ignores all changes to the work tree of submodules,
         only changes to the commits stored in the superproject are shown (this was
         the behavior until 1.7.0). Using "all" hides all changes to submodules.
 </p>
 </dd>
 <dt class="hdlist1">
 --src-prefix=&lt;prefix&gt;
 </dt>
 <dd>
 <p>
         Show the given source prefix instead of "a/".
 </p>
 </dd>
 <dt class="hdlist1">
 --dst-prefix=&lt;prefix&gt;
 </dt>
 <dd>
 <p>
         Show the given destination prefix instead of "b/".
 </p>
 </dd>
 <dt class="hdlist1">
 --no-prefix
 </dt>
 <dd>
 <p>
         Do not show any source or destination prefix.
 </p>
 </dd>
 <dt class="hdlist1">
 --line-prefix=&lt;prefix&gt;
 </dt>
 <dd>
 <p>
         Prepend an additional prefix to every line of output.
 </p>
 </dd>
 <dt class="hdlist1">
 --ita-invisible-in-index
 </dt>
 <dd>
 <p>
         By default entries added by "git add -N" appear as an existing
         empty file in "git diff" and a new file in "git diff --cached".
         This option makes the entry appear as a new file in "git diff"
         and non-existent in "git diff --cached". This option could be
         reverted with <code>--ita-visible-in-index</code>. Both options are
         experimental and could be removed in future.
 </p>
 </dd>
 </dl></div>
 <div class="paragraph"><p>For more detailed explanation on these common options, see also
 <a href="gitdiffcore.html">gitdiffcore(7)</a>.</p></div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="_generating_patches_with_p">Generating patches with -p</h2>
 <div class="sectionbody">
 <div class="paragraph"><p>When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
 with a <code>-p</code> option, "git diff" without the <code>--raw</code> option, or
 "git log" with the "-p" option, they
 do not produce the output described above; instead they produce a
 patch file.  You can customize the creation of such patches via the
 <code>GIT_EXTERNAL_DIFF</code> and the <code>GIT_DIFF_OPTS</code> environment variables.</p></div>
 <div class="paragraph"><p>What the -p option produces is slightly different from the traditional
 diff format:</p></div>
 <div class="olist arabic"><ol class="arabic">
 <li>
 <p>
 It is preceded with a "git diff" header that looks like this:
 </p>
 <div class="literalblock">
 <div class="content">
 <pre><code>diff --git a/file1 b/file2</code></pre>
 </div></div>
 <div class="paragraph"><p>The <code>a/</code> and <code>b/</code> filenames are the same unless rename/copy is
 involved.  Especially, even for a creation or a deletion,
 <code>/dev/null</code> is <em>not</em> used in place of the <code>a/</code> or <code>b/</code> filenames.</p></div>
 <div class="paragraph"><p>When rename/copy is involved, <code>file1</code> and <code>file2</code> show the
 name of the source file of the rename/copy and the name of
 the file that rename/copy produces, respectively.</p></div>
 </li>
 <li>
 <p>
 It is followed by one or more extended header lines:
 </p>
 <div class="literalblock">
 <div class="content">
 <pre><code>old mode &lt;mode&gt;
 new mode &lt;mode&gt;
 deleted file mode &lt;mode&gt;
 new file mode &lt;mode&gt;
 copy from &lt;path&gt;
 copy to &lt;path&gt;
 rename from &lt;path&gt;
 rename to &lt;path&gt;
 similarity index &lt;number&gt;
 dissimilarity index &lt;number&gt;
 index &lt;hash&gt;..&lt;hash&gt; &lt;mode&gt;</code></pre>
 </div></div>
 <div class="paragraph"><p>File modes are printed as 6-digit octal numbers including the file type
 and file permission bits.</p></div>
 <div class="paragraph"><p>Path names in extended headers do not include the <code>a/</code> and <code>b/</code> prefixes.</p></div>
 <div class="paragraph"><p>The similarity index is the percentage of unchanged lines, and
 the dissimilarity index is the percentage of changed lines.  It
 is a rounded down integer, followed by a percent sign.  The
 similarity index value of 100% is thus reserved for two equal
 files, while 100% dissimilarity means that no line from the old
 file made it into the new one.</p></div>
 <div class="paragraph"><p>The index line includes the SHA-1 checksum before and after the change.
 The &lt;mode&gt; is included if the file mode does not change; otherwise,
 separate lines indicate the old and the new mode.</p></div>
 </li>
 <li>
 <p>
 Pathnames 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>
 </li>
 <li>
 <p>
 All the <code>file1</code> files in the output refer to files before the
     commit, and all the <code>file2</code> files refer to files after the commit.
     It is incorrect to apply each change to each file sequentially.  For
     example, this patch will swap a and b:
 </p>
 <div class="literalblock">
 <div class="content">
 <pre><code>diff --git a/a b/b
 rename from a
 rename to b
 diff --git a/b b/a
 rename from b
 rename to a</code></pre>
 </div></div>
 </li>
 </ol></div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="_combined_diff_format">combined diff format</h2>
 <div class="sectionbody">
 <div class="paragraph"><p>Any diff-generating command can take the <code>-c</code> or <code>--cc</code> option to
 produce a <em>combined diff</em> when showing a merge. This is the default
 format when showing merges with <a href="git-diff.html">git-diff(1)</a> or
 <a href="git-show.html">git-show(1)</a>. Note also that you can give the <code>-m</code> option to any
 of these commands to force generation of diffs with individual parents
 of a merge.</p></div>
 <div class="paragraph"><p>A <em>combined diff</em> format looks like this:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code>diff --combined describe.c
 index fabadb8,cc95eb0..4866510
 --- a/describe.c
 +++ b/describe.c
 @@@ -98,20 -98,12 +98,20 @@@
         return (a_date &gt; b_date) ? -1 : (a_date == b_date) ? 0 : 1;
   }

 - static void describe(char *arg)
  -static void describe(struct commit *cmit, int last_one)
 ++static void describe(char *arg, int last_one)
   {
  +      unsigned char sha1[20];
  +      struct commit *cmit;
         struct commit_list *list;
         static int initialized = 0;
         struct commit_name *n;

  +      if (get_sha1(arg, sha1) &lt; 0)
  +              usage(describe_usage);
  +      cmit = lookup_commit_reference(sha1);
  +      if (!cmit)
  +              usage(describe_usage);
  +
         if (!initialized) {
                 initialized = 1;
                 for_each_ref(get_name);</code></pre>
 </div></div>
 <div class="olist arabic"><ol class="arabic">
 <li>
 <p>
 It is preceded with a "git diff" header, that looks like
      this (when <code>-c</code> option is used):
 </p>
 <div class="literalblock">
 <div class="content">
 <pre><code>diff --combined file</code></pre>
 </div></div>
 <div class="paragraph"><p>or like this (when <code>--cc</code> option is used):</p></div>
 <div class="literalblock">
 <div class="content">
 <pre><code>diff --cc file</code></pre>
 </div></div>
 </li>
 <li>
 <p>
 It is followed by one or more extended header lines
      (this example shows a merge with two parents):
 </p>
 <div class="literalblock">
 <div class="content">
 <pre><code>index &lt;hash&gt;,&lt;hash&gt;..&lt;hash&gt;
 mode &lt;mode&gt;,&lt;mode&gt;..&lt;mode&gt;
 new file mode &lt;mode&gt;
 deleted file mode &lt;mode&gt;,&lt;mode&gt;</code></pre>
 </div></div>
 <div class="paragraph"><p>The <code>mode &lt;mode&gt;,&lt;mode&gt;..&lt;mode&gt;</code> line appears only if at least one of
 the &lt;mode&gt; is different from the rest. Extended headers with
 information about detected contents movement (renames and
 copying detection) are designed to work with diff of two
 &lt;tree-ish&gt; and are not used by combined diff format.</p></div>
 </li>
 <li>
 <p>
 It is followed by two-line from-file/to-file header
 </p>
 <div class="literalblock">
 <div class="content">
 <pre><code>--- a/file
 +++ b/file</code></pre>
 </div></div>
 <div class="paragraph"><p>Similar to two-line header for traditional <em>unified</em> diff
 format, <code>/dev/null</code> is used to signal created or deleted
 files.</p></div>
 </li>
 <li>
 <p>
 Chunk header format is modified to prevent people from
      accidentally feeding it to <code>patch -p1</code>. Combined diff format
      was created for review of merge commit changes, and was not
      meant for apply. The change is similar to the change in the
      extended <em>index</em> header:
 </p>
 <div class="literalblock">
 <div class="content">
 <pre><code>@@@ &lt;from-file-range&gt; &lt;from-file-range&gt; &lt;to-file-range&gt; @@@</code></pre>
 </div></div>
 <div class="paragraph"><p>There are (number of parents + 1) <code>@</code> characters in the chunk
 header for combined diff format.</p></div>
 </li>
 </ol></div>
 <div class="paragraph"><p>Unlike the traditional <em>unified</em> diff format, which shows two
 files A and B with a single column that has <code>-</code> (minus&#8201;&#8212;&#8201;appears in A but removed in B), <code>+</code> (plus&#8201;&#8212;&#8201;missing in A but
 added to B), or <code>" "</code> (space&#8201;&#8212;&#8201;unchanged) prefix, this format
 compares two or more files file1, file2,&#8230; with one file X, and
 shows how X differs from each of fileN.  One column for each of
 fileN is prepended to the output line to note how X&#8217;s line is
 different from it.</p></div>
 <div class="paragraph"><p>A <code>-</code> character in the column N means that the line appears in
 fileN but it does not appear in the result.  A <code>+</code> character
 in the column N means that the line appears in the result,
 and fileN does not have that line (in other words, the line was
 added, from the point of view of that parent).</p></div>
 <div class="paragraph"><p>In the above example output, the function signature was changed
 from both files (hence two <code>-</code> removals from both file1 and
 file2, plus <code>++</code> to mean one line that was added does not appear
 in either file1 or file2).  Also eight other lines are the same
 from file1 but do not appear in file2 (hence prefixed with <code>+</code>).</p></div>
 <div class="paragraph"><p>When shown by <code>git diff-tree -c</code>, it compares the parents of a
 merge commit with the merge result (i.e. file1..fileN are the
 parents).  When shown by <code>git diff-files -c</code>, it compares the
 two unresolved merge parents with the working tree file
 (i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka
 "their version").</p></div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="_examples">EXAMPLES</h2>
 <div class="sectionbody">
 <div class="dlist"><dl>
 <dt class="hdlist1">
 <code>git log --no-merges</code>
 </dt>
 <dd>
 <p>
         Show the whole commit history, but skip any merges
 </p>
 </dd>
 <dt class="hdlist1">
 <code>git log v2.6.12.. include/scsi drivers/scsi</code>
 </dt>
 <dd>
 <p>
         Show all commits since version <em>v2.6.12</em> that changed any file
         in the <code>include/scsi</code> or <code>drivers/scsi</code> subdirectories
 </p>
 </dd>
 <dt class="hdlist1">
 <code>git log --since="2 weeks ago" -- gitk</code>
 </dt>
 <dd>
 <p>
         Show the changes during the last two weeks to the file <em>gitk</em>.
         The <code>--</code> is necessary to avoid confusion with the <strong>branch</strong> named
         <em>gitk</em>
 </p>
 </dd>
 <dt class="hdlist1">
 <code>git log --name-status release..test</code>
 </dt>
 <dd>
 <p>
         Show the commits that are in the "test" branch but not yet
         in the "release" branch, along with the list of paths
         each commit modifies.
 </p>
 </dd>
 <dt class="hdlist1">
 <code>git log --follow builtin/rev-list.c</code>
 </dt>
 <dd>
 <p>
         Shows the commits that changed <code>builtin/rev-list.c</code>, including
         those commits that occurred before the file was given its
         present name.
 </p>
 </dd>
 <dt class="hdlist1">
 <code>git log --branches --not --remotes=origin</code>
 </dt>
 <dd>
 <p>
         Shows all commits that are in any of local branches but not in
         any of remote-tracking branches for <em>origin</em> (what you have that
         origin doesn&#8217;t).
 </p>
 </dd>
 <dt class="hdlist1">
 <code>git log master --not --remotes=*/master</code>
 </dt>
 <dd>
 <p>
         Shows all commits that are in local master but not in any remote
         repository master branches.
 </p>
 </dd>
 <dt class="hdlist1">
 <code>git log -p -m --first-parent</code>
 </dt>
 <dd>
 <p>
         Shows the history including change diffs, but only from the
         &#8220;main branch&#8221; perspective, skipping commits that come from merged
         branches, and showing full diffs of changes introduced by the merges.
         This makes sense only when following a strict policy of merging all
         topic branches when staying on a single integration branch.
 </p>
 </dd>
 <dt class="hdlist1">
 <code>git log -L '/int main/',/^}/:main.c</code>
 </dt>
 <dd>
 <p>
         Shows how the function <code>main()</code> in the file <code>main.c</code> evolved
         over time.
 </p>
 </dd>
 <dt class="hdlist1">
 <code>git log -3</code>
 </dt>
 <dd>
 <p>
         Limits the number of commits to show to 3.
 </p>
 </dd>
 </dl></div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="_discussion">DISCUSSION</h2>
 <div class="sectionbody">
 <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 i18n.commitencoding 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="_configuration">CONFIGURATION</h2>
 <div class="sectionbody">
 <div class="paragraph"><p>See <a href="git-config.html">git-config(1)</a> for core variables and <a href="git-diff.html">git-diff(1)</a>
 for settings related to diff generation.</p></div>
 <div class="dlist"><dl>
 <dt class="hdlist1">
 format.pretty
 </dt>
 <dd>
 <p>
         Default for the <code>--format</code> option.  (See <em>Pretty Formats</em> above.)
         Defaults to <code>medium</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 i18n.logOutputEncoding
 </dt>
 <dd>
 <p>
         Encoding to use when displaying logs.  (See <em>Discussion</em> above.)
         Defaults to the value of <code>i18n.commitEncoding</code> if set, and UTF-8
         otherwise.
 </p>
 </dd>
 <dt class="hdlist1">
 log.date
 </dt>
 <dd>
 <p>
         Default format for human-readable dates.  (Compare the
         <code>--date</code> option.)  Defaults to "default", which means to write
         dates like <code>Sat May 8 19:35:34 2010 -0500</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 log.follow
 </dt>
 <dd>
 <p>
         If <code>true</code>, <code>git log</code> will act as if the <code>--follow</code> option was used when
         a single &lt;path&gt; is given.  This has the same limitations as <code>--follow</code>,
         i.e. it cannot be used to follow multiple files and does not work well
         on non-linear history.
 </p>
 </dd>
 <dt class="hdlist1">
 log.showRoot
 </dt>
 <dd>
 <p>
         If <code>false</code>, <code>git log</code> and related commands will not treat the
         initial commit as a big creation event.  Any root commits in
         <code>git log -p</code> output would be shown without a diff attached.
         The default is <code>true</code>.
 </p>
 </dd>
 <dt class="hdlist1">
 log.showSignature
 </dt>
 <dd>
 <p>
         If <code>true</code>, <code>git log</code> and related commands will act as if the
         <code>--show-signature</code> option was passed to them.
 </p>
 </dd>
 <dt class="hdlist1">
 mailmap.*
 </dt>
 <dd>
 <p>
         See <a href="git-shortlog.html">git-shortlog(1)</a>.
 </p>
 </dd>
 <dt class="hdlist1">
 notes.displayRef
 </dt>
 <dd>
 <p>
         Which refs, in addition to the default set by <code>core.notesRef</code>
         or <code>GIT_NOTES_REF</code>, to read notes from when showing commit
         messages with the <code>log</code> family of commands.  See
         <a href="git-notes.html">git-notes(1)</a>.
 </p>
 <div class="paragraph"><p>May be an unabbreviated ref name or a glob and may be specified
 multiple times.  A warning will be issued for refs that do not exist,
 but a glob that does not match any refs is silently ignored.</p></div>
 <div class="paragraph"><p>This setting can be disabled by the <code>--no-notes</code> option,
 overridden by the <code>GIT_NOTES_DISPLAY_REF</code> environment variable,
 and overridden by the <code>--notes=&lt;ref&gt;</code> option.</p></div>
 </dd>
 </dl></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
  2018-05-08 16:51:20 JST
 </div>
 </div>
 </body>
 </html>