git-shortlog.html - external/gitster/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 9.0.0rc2" />
 <title>git-shortlog(1)</title>
 <style type="text/css">
 /* Shared CSS for AsciiDoc xhtml11 and html5 backends */

 /* Default font. */
 body {
  font-family: Georgia,serif;
 }

 /* Title font. */
 h1, h2, h3, h4, h5, h6,
 div.title, caption.title,
 thead, p.table.header,
 #toctitle,
 #author, #revnumber, #revdate, #revremark,
 #footer {
  font-family: Arial,Helvetica,sans-serif;
 }

 body {
  margin: 1em 5% 1em 5%;
 }

 a {
  color: blue;
  text-decoration: underline;
 }
 a:visited {
  color: fuchsia;
 }

 em {
  font-style: italic;
  color: navy;
 }

 strong {
  font-weight: bold;
  color: #083194;
 }

 h1, h2, h3, h4, h5, h6 {
  color: #527bbd;
  margin-top: 1.2em;
  margin-bottom: 0.5em;
  line-height: 1.3;
 }

 h1, h2, h3 {
  border-bottom: 2px solid silver;
 }
 h2 {
  padding-top: 0.5em;
 }
 h3 {
  float: left;
 }
 h3 + * {
  clear: left;
 }
 h5 {
  font-size: 1.0em;
 }

 div.sectionbody {
  margin-left: 0;
 }

 hr {
  border: 1px solid silver;
 }

 p {
  margin-top: 0.5em;
  margin-bottom: 0.5em;
 }

 ul, ol, li > p {
  margin-top: 0;
 }
 ul > li { color: #aaa; }
 ul > li > * { color: black; }

 .monospaced, code, pre {
  font-family: "Courier New", Courier, monospace;
  font-size: inherit;
  color: navy;
  padding: 0;
  margin: 0;
 }
 pre {
  white-space: pre-wrap;
 }

 #author {
  color: #527bbd;
  font-weight: bold;
  font-size: 1.1em;
 }
 #email {
 }
 #revnumber, #revdate, #revremark {
 }

 #footer {
  font-size: small;
  border-top: 2px solid silver;
  padding-top: 0.5em;
  margin-top: 4.0em;
 }
 #footer-text {
  float: left;
  padding-bottom: 0.5em;
 }
 #footer-badges {
  float: right;
  padding-bottom: 0.5em;
 }

 #preamble {
  margin-top: 1.5em;
  margin-bottom: 1.5em;
 }
 div.imageblock, div.exampleblock, div.verseblock,
 div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
 div.admonitionblock {
  margin-top: 1.0em;
  margin-bottom: 1.5em;
 }
 div.admonitionblock {
  margin-top: 2.0em;
  margin-bottom: 2.0em;
  margin-right: 10%;
  color: #606060;
 }

 div.content { /* Block element content. */
  padding: 0;
 }

 /* Block element titles. */
 div.title, caption.title {
  color: #527bbd;
  font-weight: bold;
  text-align: left;
  margin-top: 1.0em;
  margin-bottom: 0.5em;
 }
 div.title + * {
  margin-top: 0;
 }

 td div.title:first-child {
  margin-top: 0.0em;
 }
 div.content div.title:first-child {
  margin-top: 0.0em;
 }
 div.content + div.title {
  margin-top: 0.0em;
 }

 div.sidebarblock > div.content {
  background: #ffffee;
  border: 1px solid #dddddd;
  border-left: 4px solid #f0f0f0;
  padding: 0.5em;
 }

 div.listingblock > div.content {
  border: 1px solid #dddddd;
  border-left: 5px solid #f0f0f0;
  background: #f8f8f8;
  padding: 0.5em;
 }

 div.quoteblock, div.verseblock {
  padding-left: 1.0em;
  margin-left: 1.0em;
  margin-right: 10%;
  border-left: 5px solid #f0f0f0;
  color: #888;
 }

 div.quoteblock > div.attribution {
  padding-top: 0.5em;
  text-align: right;
 }

 div.verseblock > pre.content {
  font-family: inherit;
  font-size: inherit;
 }
 div.verseblock > div.attribution {
  padding-top: 0.75em;
  text-align: left;
 }
 /* DEPRECATED: Pre version 8.2.7 verse style literal block. */
 div.verseblock + div.attribution {
  text-align: left;
 }

 div.admonitionblock .icon {
  vertical-align: top;
  font-size: 1.1em;
  font-weight: bold;
  text-decoration: underline;
  color: #527bbd;
  padding-right: 0.5em;
 }
 div.admonitionblock td.content {
  padding-left: 0.5em;
  border-left: 3px solid #dddddd;
 }

 div.exampleblock > div.content {
  border-left: 3px solid #dddddd;
  padding-left: 0.5em;
 }

 div.imageblock div.content { padding-left: 0; }
 span.image img { border-style: none; vertical-align: text-bottom; }
 a.image:visited { color: white; }

 dl {
  margin-top: 0.8em;
  margin-bottom: 0.8em;
 }
 dt {
  margin-top: 0.5em;
  margin-bottom: 0;
  font-style: normal;
  color: navy;
 }
 dd > *:first-child {
  margin-top: 0.1em;
 }

 ul, ol {
  list-style-position: outside;
 }
 ol.arabic {
  list-style-type: decimal;
 }
 ol.loweralpha {
  list-style-type: lower-alpha;
 }
 ol.upperalpha {
  list-style-type: upper-alpha;
 }
 ol.lowerroman {
  list-style-type: lower-roman;
 }
 ol.upperroman {
  list-style-type: upper-roman;
 }

 div.compact ul, div.compact ol,
 div.compact p, div.compact p,
 div.compact div, div.compact div {
  margin-top: 0.1em;
  margin-bottom: 0.1em;
 }

 tfoot {
  font-weight: bold;
 }
 td > div.verse {
  white-space: pre;
 }

 div.hdlist {
  margin-top: 0.8em;
  margin-bottom: 0.8em;
 }
 div.hdlist tr {
  padding-bottom: 15px;
 }
 dt.hdlist1.strong, td.hdlist1.strong {
  font-weight: bold;
 }
 td.hdlist1 {
  vertical-align: top;
  font-style: normal;
  padding-right: 0.8em;
  color: navy;
 }
 td.hdlist2 {
  vertical-align: top;
 }
 div.hdlist.compact tr {
  margin: 0;
  padding-bottom: 0;
 }

 .comment {
  background: yellow;
 }

 .footnote, .footnoteref {
  font-size: 0.8em;
 }

 span.footnote, span.footnoteref {
  vertical-align: super;
 }

 #footnotes {
  margin: 20px 0 20px 0;
  padding: 7px 0 0 0;
 }

 #footnotes div.footnote {
  margin: 0 0 5px 0;
 }

 #footnotes hr {
  border: none;
  border-top: 1px solid silver;
  height: 1px;
  text-align: left;
  margin-left: 0;
  width: 20%;
  min-width: 100px;
 }

 div.colist td {
  padding-right: 0.5em;
  padding-bottom: 0.3em;
  vertical-align: top;
 }
 div.colist td img {
  margin-top: 0.3em;
 }

 @media print {
  #footer-badges { display: none; }
 }

 #toc {
  margin-bottom: 2.5em;
 }

 #toctitle {
  color: #527bbd;
  font-size: 1.1em;
  font-weight: bold;
  margin-top: 1.0em;
  margin-bottom: 0.1em;
 }

 div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
  margin-top: 0;
  margin-bottom: 0;
 }
 div.toclevel2 {
  margin-left: 2em;
  font-size: 0.9em;
 }
 div.toclevel3 {
  margin-left: 4em;
  font-size: 0.9em;
 }
 div.toclevel4 {
  margin-left: 6em;
  font-size: 0.9em;
 }

 span.aqua { color: aqua; }
 span.black { color: black; }
 span.blue { color: blue; }
 span.fuchsia { color: fuchsia; }
 span.gray { color: gray; }
 span.green { color: green; }
 span.lime { color: lime; }
 span.maroon { color: maroon; }
 span.navy { color: navy; }
 span.olive { color: olive; }
 span.purple { color: purple; }
 span.red { color: red; }
 span.silver { color: silver; }
 span.teal { color: teal; }
 span.white { color: white; }
 span.yellow { color: yellow; }

 span.aqua-background { background: aqua; }
 span.black-background { background: black; }
 span.blue-background { background: blue; }
 span.fuchsia-background { background: fuchsia; }
 span.gray-background { background: gray; }
 span.green-background { background: green; }
 span.lime-background { background: lime; }
 span.maroon-background { background: maroon; }
 span.navy-background { background: navy; }
 span.olive-background { background: olive; }
 span.purple-background { background: purple; }
 span.red-background { background: red; }
 span.silver-background { background: silver; }
 span.teal-background { background: teal; }
 span.white-background { background: white; }
 span.yellow-background { background: yellow; }

 span.big { font-size: 2em; }
 span.small { font-size: 0.6em; }

 span.underline { text-decoration: underline; }
 span.overline { text-decoration: overline; }
 span.line-through { text-decoration: line-through; }

 div.unbreakable { page-break-inside: avoid; }


 /*
  * xhtml11 specific
  *
  * */

 div.tableblock {
  margin-top: 1.0em;
  margin-bottom: 1.5em;
 }
 div.tableblock > table {
  border: 3px solid #527bbd;
 }
 thead, p.table.header {
  font-weight: bold;
  color: #527bbd;
 }
 p.table {
  margin-top: 0;
 }
 /* Because the table frame attribute is overridden by CSS in most browsers. */
 div.tableblock > table[frame="void"] {
  border-style: none;
 }
 div.tableblock > table[frame="hsides"] {
  border-left-style: none;
  border-right-style: none;
 }
 div.tableblock > table[frame="vsides"] {
  border-top-style: none;
  border-bottom-style: none;
 }


 /*
  * html5 specific
  *
  * */

 table.tableblock {
  margin-top: 1.0em;
  margin-bottom: 1.5em;
 }
 thead, p.tableblock.header {
  font-weight: bold;
  color: #527bbd;
 }
 p.tableblock {
  margin-top: 0;
 }
 table.tableblock {
  border-width: 3px;
  border-spacing: 0px;
  border-style: solid;
  border-color: #527bbd;
  border-collapse: collapse;
 }
 th.tableblock, td.tableblock {
  border-width: 1px;
  padding: 4px;
  border-style: solid;
  border-color: #527bbd;
 }

 table.tableblock.frame-topbot {
  border-left-style: hidden;
  border-right-style: hidden;
 }
 table.tableblock.frame-sides {
  border-top-style: hidden;
  border-bottom-style: hidden;
 }
 table.tableblock.frame-none {
  border-style: hidden;
 }

 th.tableblock.halign-left, td.tableblock.halign-left {
  text-align: left;
 }
 th.tableblock.halign-center, td.tableblock.halign-center {
  text-align: center;
 }
 th.tableblock.halign-right, td.tableblock.halign-right {
  text-align: right;
 }

 th.tableblock.valign-top, td.tableblock.valign-top {
  vertical-align: top;
 }
 th.tableblock.valign-middle, td.tableblock.valign-middle {
  vertical-align: middle;
 }
 th.tableblock.valign-bottom, td.tableblock.valign-bottom {
  vertical-align: bottom;
 }


 /*
  * manpage specific
  *
  * */

 body.manpage h1 {
  padding-top: 0.5em;
  padding-bottom: 0.5em;
  border-top: 2px solid silver;
  border-bottom: 2px solid silver;
 }
 body.manpage h2 {
  border-style: none;
 }
 body.manpage div.sectionbody {
  margin-left: 3em;
 }

 @media print {
  body.manpage div#toc { display: none; }
 }


 </style>
 <script type="text/javascript">
 /*<![CDATA[*/
 var asciidoc = { // Namespace.

 /////////////////////////////////////////////////////////////////////
 // Table Of Contents generator
 /////////////////////////////////////////////////////////////////////

 /* Author: Mihai Bazon, September 2002
  * http://students.infoiasi.ro/~mishoo
  *
  * Table Of Content generator
  * Version: 0.4
  *
  * Feel free to use this script under the terms of the GNU General Public
  * License, as long as you do not remove or alter this notice.
  */

  /* modified by Troy D. Hanson, September 2006. License: GPL */
  /* modified by Stuart Rackham, 2006, 2009. License: GPL */

 // toclevels = 1..4.
 toc: function (toclevels) {

  function getText(el) {
  var text = "";
  for (var i = el.firstChild; i != null; i = i.nextSibling) {
  if (i.nodeType == 3 /* Node.TEXT_NODE */) // IE doesn't speak constants.
  text += i.data;
  else if (i.firstChild != null)
  text += getText(i);
  }
  return text;
  }

  function TocEntry(el, text, toclevel) {
  this.element = el;
  this.text = text;
  this.toclevel = toclevel;
  }

  function tocEntries(el, toclevels) {
  var result = new Array;
  var re = new RegExp('[hH]([1-'+(toclevels+1)+'])');
  // Function that scans the DOM tree for header elements (the DOM2
  // nodeIterator API would be a better technique but not supported by all
  // browsers).
  var iterate = function (el) {
  for (var i = el.firstChild; i != null; i = i.nextSibling) {
  if (i.nodeType == 1 /* Node.ELEMENT_NODE */) {
  var mo = re.exec(i.tagName);
  if (mo && (i.getAttribute("class") || i.getAttribute("className")) != "float") {
  result[result.length] = new TocEntry(i, getText(i), mo[1]-1);
  }
  iterate(i);
  }
  }
  }
  iterate(el);
  return result;
  }

  var toc = document.getElementById("toc");
  if (!toc) {
  return;
  }

  // Delete existing TOC entries in case we're reloading the TOC.
  var tocEntriesToRemove = [];
  var i;
  for (i = 0; i < toc.childNodes.length; i++) {
  var entry = toc.childNodes[i];
  if (entry.nodeName.toLowerCase() == 'div'
  && entry.getAttribute("class")
  && entry.getAttribute("class").match(/^toclevel/))
  tocEntriesToRemove.push(entry);
  }
  for (i = 0; i < tocEntriesToRemove.length; i++) {
  toc.removeChild(tocEntriesToRemove[i]);
  }

  // Rebuild TOC entries.
  var entries = tocEntries(document.getElementById("content"), toclevels);
  for (var i = 0; i < entries.length; ++i) {
  var entry = entries[i];
  if (entry.element.id == "")
  entry.element.id = "_toc_" + i;
  var a = document.createElement("a");
  a.href = "#" + entry.element.id;
  a.appendChild(document.createTextNode(entry.text));
  var div = document.createElement("div");
  div.appendChild(a);
  div.className = "toclevel" + entry.toclevel;
  toc.appendChild(div);
  }
  if (entries.length == 0)
  toc.parentNode.removeChild(toc);
 },


 /////////////////////////////////////////////////////////////////////
 // Footnotes generator
 /////////////////////////////////////////////////////////////////////

 /* Based on footnote generation code from:
  * http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
  */

 footnotes: function () {
  // Delete existing footnote entries in case we're reloading the footnodes.
  var i;
  var noteholder = document.getElementById("footnotes");
  if (!noteholder) {
  return;
  }
  var entriesToRemove = [];
  for (i = 0; i < noteholder.childNodes.length; i++) {
  var entry = noteholder.childNodes[i];
  if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote")
  entriesToRemove.push(entry);
  }
  for (i = 0; i < entriesToRemove.length; i++) {
  noteholder.removeChild(entriesToRemove[i]);
  }

  // Rebuild footnote entries.
  var cont = document.getElementById("content");
  var spans = cont.getElementsByTagName("span");
  var refs = {};
  var n = 0;
  for (i=0; i<spans.length; i++) {
  if (spans[i].className == "footnote") {
  n++;
  var note = spans[i].getAttribute("data-note");
  if (!note) {
  // Use [\s\S] in place of . so multi-line matches work.
  // Because JavaScript has no s (dotall) regex flag.
  note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[1];
  spans[i].innerHTML =
  "[<a id='_footnoteref_" + n + "' href='#_footnote_" + n +
  "' title='View footnote' class='footnote'>" + n + "</a>]";
  spans[i].setAttribute("data-note", note);
  }
  noteholder.innerHTML +=
  "<div class='footnote' id='_footnote_" + n + "'>" +
  "<a href='#_footnoteref_" + n + "' title='Return to text'>" +
  n + "</a>. " + note + "</div>";
  var id =spans[i].getAttribute("id");
  if (id != null) refs["#"+id] = n;
  }
  }
  if (n == 0)
  noteholder.parentNode.removeChild(noteholder);
  else {
  // Process footnoterefs.
  for (i=0; i<spans.length; i++) {
  if (spans[i].className == "footnoteref") {
  var href = spans[i].getElementsByTagName("a")[0].getAttribute("href");
  href = href.match(/#.*/)[0]; // Because IE return full URL.
  n = refs[href];
  spans[i].innerHTML =
  "[<a href='#_footnote_" + n +
  "' title='View footnote' class='footnote'>" + n + "</a>]";
  }
  }
  }
 },

 install: function(toclevels) {
  var timerId;

  function reinstall() {
  asciidoc.footnotes();
  if (toclevels) {
  asciidoc.toc(toclevels);
  }
  }

  function reinstallAndRemoveTimer() {
  clearInterval(timerId);
  reinstall();
  }

  timerId = setInterval(reinstall, 500);
  if (document.addEventListener)
  document.addEventListener("DOMContentLoaded", reinstallAndRemoveTimer, false);
  else
  window.onload = reinstallAndRemoveTimer;
 }

 }
 asciidoc.install();
 /*]]>*/
 </script>
 </head>
 <body class="manpage">
 <div id="header">
 <h1>
 git-shortlog(1) Manual Page
 </h1>
 <h2>NAME</h2>
 <div class="sectionbody">
 <p>git-shortlog -
  Summarize 'git log' output
 </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 shortlog</em> [&lt;options&gt;] [&lt;revision range&gt;] [[--] &lt;path&gt;&#8230;]
 git log --pretty=short | <em>git shortlog</em> [&lt;options&gt;]</pre>
 <div class="attribution">
 </div></div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="_description">DESCRIPTION</h2>
 <div class="sectionbody">
 <div class="paragraph"><p>Summarizes <em>git log</em> output in a format suitable for inclusion
 in release announcements. Each commit will be grouped by author and title.</p></div>
 <div class="paragraph"><p>Additionally, "[PATCH]" will be stripped from the commit description.</p></div>
 <div class="paragraph"><p>If no revisions are passed on the command line and either standard input
 is not a terminal or there is no current branch, <em>git shortlog</em> will
 output a summary of the log read from standard input, without
 reference to the current repository.</p></div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="_options">OPTIONS</h2>
 <div class="sectionbody">
 <div class="dlist"><dl>
 <dt class="hdlist1">
 -n
 </dt>
 <dt class="hdlist1">
 --numbered
 </dt>
 <dd>
 <p>
  Sort output according to the number of commits per author instead
  of author alphabetic order.
 </p>
 </dd>
 <dt class="hdlist1">
 -s
 </dt>
 <dt class="hdlist1">
 --summary
 </dt>
 <dd>
 <p>
  Suppress commit description and provide a commit count summary only.
 </p>
 </dd>
 <dt class="hdlist1">
 -e
 </dt>
 <dt class="hdlist1">
 --email
 </dt>
 <dd>
 <p>
  Show the email address of each author.
 </p>
 </dd>
 <dt class="hdlist1">
 --format[=&lt;format&gt;]
 </dt>
 <dd>
 <p>
  Instead of the commit subject, use some other information to
  describe each commit. <em>&lt;format&gt;</em> can be any string accepted
  by the <code>--format</code> option of <em>git log</em>, such as <em>* [%h] %s</em>.
  (See the "PRETTY FORMATS" section of <a href="git-log.html">git-log(1)</a>.)
 </p>
 <div class="literalblock">
 <div class="content">
 <pre><code>Each pretty-printed commit will be rewrapped before it is shown.</code></pre>
 </div></div>
 </dd>
 <dt class="hdlist1">
 -c
 </dt>
 <dt class="hdlist1">
 --committer
 </dt>
 <dd>
 <p>
  Collect and show committer identities instead of authors.
 </p>
 </dd>
 <dt class="hdlist1">
 -w[&lt;width&gt;[,&lt;indent1&gt;[,&lt;indent2&gt;]]]
 </dt>
 <dd>
 <p>
  Linewrap the output by wrapping each line at <code>width</code>. The first
  line of each entry is indented by <code>indent1</code> spaces, and the second
  and subsequent lines are indented by <code>indent2</code> spaces. <code>width</code>,
  <code>indent1</code>, and <code>indent2</code> default to 76, 6 and 9 respectively.
 </p>
 <div class="paragraph"><p>If width is <code>0</code> (zero) then indent the lines of the output without wrapping
 them.</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 "Specifying Ranges"
  section of <a href="gitrevisions.html">gitrevisions(7)</a>.
 </p>
 </dd>
 <dt class="hdlist1">
 [--] &lt;path&gt;&#8230;
 </dt>
 <dd>
 <p>
  Consider only commits that are enough to explain how the files
  that match the specified paths came to be.
 </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="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>--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.
 </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">
 --alternate-refs
 </dt>
 <dd>
 <p>
  Pretend as if all objects mentioned as ref tips of alternate
  repositories were listed on the command line. An alternate
  repository is any repository whose object directory is specified
  in <code>objects/info/alternates</code>. The set of included objects may
  be modified by <code>core.alternateRefsCommand</code>, etc. See
  <a href="git-config.html">git-config(1)</a>.
 </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.
 </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> and <code>reference</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>
 <div class="paragraph"><p>Under <code>--pretty=reference</code>, this information will not be shown at all.</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 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">
 --show-pulls
 </dt>
 <dd>
 <p>
  Include all commits from the default mode, but also any merge
  commits that are not TREESAME to the first parent but are
  TREESAME to a later parent. This mode is helpful for showing
  the merge commits that "first introduced" a change to a branch.
 </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>There is another 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>Before discussing another option, <code>--show-pulls</code>, we need to
 create a new example history.</p></div>
 <div class="paragraph"><p>A common problem users face when looking at simplified history is that a
 commit they know changed a file somehow does not appear in the file&#8217;s
 simplified history. Let&#8217;s demonstrate a new example and show how options
 such as <code>--full-history</code> and <code>--simplify-merges</code> works in that case:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code> .-A---M-----C--N---O---P
  / / \ \ \/ / /
  I B \ R-'`-Z' /
  \ / \/ /
  \ / /\ /
  `---X--' `---Y--'</code></pre>
 </div></div>
 <div class="paragraph"><p>For this example, suppose <code>I</code> created <code>file.txt</code> which was modified by
 <code>A</code>, <code>B</code>, and <code>X</code> in different ways. The single-parent commits <code>C</code>, <code>Z</code>,
 and <code>Y</code> do not change <code>file.txt</code>. The merge commit <code>M</code> was created by
 resolving the merge conflict to include both changes from <code>A</code> and <code>B</code>
 and hence is not TREESAME to either. The merge commit <code>R</code>, however, was
 created by ignoring the contents of <code>file.txt</code> at <code>M</code> and taking only
 the contents of <code>file.txt</code> at <code>X</code>. Hence, <code>R</code> is TREESAME to <code>X</code> but not
 <code>M</code>. Finally, the natural merge resolution to create <code>N</code> is to take the
 contents of <code>file.txt</code> at <code>R</code>, so <code>N</code> is TREESAME to <code>R</code> but not <code>C</code>.
 The merge commits <code>O</code> and <code>P</code> are TREESAME to their first parents, but
 not to their second parents, <code>Z</code> and <code>Y</code> respectively.</p></div>
 <div class="paragraph"><p>When using the default mode, <code>N</code> and <code>R</code> both have a TREESAME parent, so
 those edges are walked and the others are ignored. The resulting history
 graph is:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code> I---X</code></pre>
 </div></div>
 <div class="paragraph"><p>When using <code>--full-history</code>, Git walks every edge. This will discover
 the commits <code>A</code> and <code>B</code> and the merge <code>M</code>, but also will reveal the
 merge commits <code>O</code> and <code>P</code>. With parent rewriting, the resulting graph is:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code> .-A---M--------N---O---P
  / / \ \ \/ / /
  I B \ R-'`--' /
  \ / \/ /
  \ / /\ /
  `---X--' `------'</code></pre>
 </div></div>
 <div class="paragraph"><p>Here, the merge commits <code>O</code> and <code>P</code> contribute extra noise, as they did
 not actually contribute a change to <code>file.txt</code>. They only merged a topic
 that was based on an older version of <code>file.txt</code>. This is a common
 issue in repositories using a workflow where many contributors work in
 parallel and merge their topic branches along a single trunk: manu
 unrelated merges appear in the <code>--full-history</code> results.</p></div>
 <div class="paragraph"><p>When using the <code>--simplify-merges</code> option, the commits <code>O</code> and <code>P</code>
 disappear from the results. This is because the rewritten second parents
 of <code>O</code> and <code>P</code> are reachable from their first parents. Those edges are
 removed and then the commits look like single-parent commits that are
 TREESAME to their parent. This also happens to the commit <code>N</code>, resulting
 in a history view as follows:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code> .-A---M--.
  / / \
  I B R
  \ / /
  \ / /
  `---X--'</code></pre>
 </div></div>
 <div class="paragraph"><p>In this view, we see all of the important single-parent changes from
 <code>A</code>, <code>B</code>, and <code>X</code>. We also see the carefully-resolved merge <code>M</code> and the
 not-so-carefully-resolved merge <code>R</code>. This is usually enough information
 to determine why the commits <code>A</code> and <code>B</code> "disappeared" from history in
 the default view. However, there are a few issues with this approach.</p></div>
 <div class="paragraph"><p>The first issue is performance. Unlike any previous option, the
 <code>--simplify-merges</code> option requires walking the entire commit history
 before returning a single result. This can make the option difficult to
 use for very large repositories.</p></div>
 <div class="paragraph"><p>The second issue is one of auditing. When many contributors are working
 on the same repository, it is important which merge commits introduced
 a change into an important branch. The problematic merge <code>R</code> above is
 not likely to be the merge commit that was used to merge into an
 important branch. Instead, the merge <code>N</code> was used to merge <code>R</code> and <code>X</code>
 into the important branch. This commit may have information about why
 the change <code>X</code> came to override the changes from <code>A</code> and <code>B</code> in its
 commit message.</p></div>
 <div class="dlist"><dl>
 <dt class="hdlist1">
 --show-pulls
 </dt>
 <dd>
 <p>
  In addition to the commits shown in the default history, show
  each merge commit that is not TREESAME to its first parent but
  is TREESAME to a later parent.
 </p>
 <div class="paragraph"><p>When a merge commit is included by <code>--show-pulls</code>, the merge is
 treated as if it "pulled" the change from another branch. When using
 <code>--show-pulls</code> on this example (and no other options) the resulting
 graph is:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code> I---X---R---N</code></pre>
 </div></div>
 <div class="paragraph"><p>Here, the merge commits <code>R</code> and <code>N</code> are included because they pulled
 the commits <code>X</code> and <code>R</code> into the base branch, respectively. These
 merges are the reason the commits <code>A</code> and <code>B</code> do not appear in the
 default history.</p></div>
 <div class="paragraph"><p>When <code>--show-pulls</code> is paired with <code>--simplify-merges</code>, the
 graph includes all of the necessary information:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code> .-A---M--. N
  / / \ /
  I B R
  \ / /
  \ / /
  `---X--'</code></pre>
 </div></div>
 <div class="paragraph"><p>Notice that since <code>M</code> is reachable from <code>R</code>, the edge from <code>N</code> to <code>M</code>
 was simplified away. However, <code>N</code> still appears in the history as an
 important commit because it "pulled" the change <code>R</code> into the main
 branch.</p></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>
 </div>
 <div class="sect1">
 <h2 id="_mapping_authors">MAPPING AUTHORS</h2>
 <div class="sectionbody">
 <div class="paragraph"><p>The <code>.mailmap</code> feature is used to coalesce together commits by the same
 person in the shortlog, where their name and/or email address was
 spelled differently.</p></div>
 <div class="paragraph"><p>If the file <code>.mailmap</code> exists at the toplevel of the repository, or at
 the location pointed to by the mailmap.file or mailmap.blob
 configuration options, it
 is used to map author and committer names and email addresses to
 canonical real names and email addresses.</p></div>
 <div class="paragraph"><p>In the simple form, each line in the file consists of the canonical
 real name of an author, whitespace, and an email address used in the
 commit (enclosed by <em>&lt;</em> and <em>&gt;</em>) to map to the name. For example:</p></div>
 <div class="openblock">
 <div class="content">
 <div class="literalblock">
 <div class="content">
 <pre><code>Proper Name &lt;commit@email.xx&gt;</code></pre>
 </div></div>
 </div></div>
 <div class="paragraph"><p>The more complex forms are:</p></div>
 <div class="openblock">
 <div class="content">
 <div class="literalblock">
 <div class="content">
 <pre><code>&lt;proper@email.xx&gt; &lt;commit@email.xx&gt;</code></pre>
 </div></div>
 </div></div>
 <div class="paragraph"><p>which allows mailmap to replace only the email part of a commit, and:</p></div>
 <div class="openblock">
 <div class="content">
 <div class="literalblock">
 <div class="content">
 <pre><code>Proper Name &lt;proper@email.xx&gt; &lt;commit@email.xx&gt;</code></pre>
 </div></div>
 </div></div>
 <div class="paragraph"><p>which allows mailmap to replace both the name and the email of a
 commit matching the specified commit email address, and:</p></div>
 <div class="openblock">
 <div class="content">
 <div class="literalblock">
 <div class="content">
 <pre><code>Proper Name &lt;proper@email.xx&gt; Commit Name &lt;commit@email.xx&gt;</code></pre>
 </div></div>
 </div></div>
 <div class="paragraph"><p>which allows mailmap to replace both the name and the email of a
 commit matching both the specified commit name and email address.</p></div>
 <div class="paragraph"><p>Example 1: Your history contains commits by two authors, Jane
 and Joe, whose names appear in the repository under several forms:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code>Joe Developer &lt;joe@example.com&gt;
 Joe R. Developer &lt;joe@example.com&gt;
 Jane Doe &lt;jane@example.com&gt;
 Jane Doe &lt;jane@laptop.(none)&gt;
 Jane D. &lt;jane@desktop.(none)&gt;</code></pre>
 </div></div>
 <div class="paragraph"><p>Now suppose that Joe wants his middle name initial used, and Jane
 prefers her family name fully spelled out. A proper <code>.mailmap</code> file
 would look like:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code>Jane Doe &lt;jane@desktop.(none)&gt;
 Joe R. Developer &lt;joe@example.com&gt;</code></pre>
 </div></div>
 <div class="paragraph"><p>Note how there is no need for an entry for <code>&lt;jane@laptop.(none)&gt;</code>, because the
 real name of that author is already correct.</p></div>
 <div class="paragraph"><p>Example 2: Your repository contains commits from the following
 authors:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code>nick1 &lt;bugs@company.xx&gt;
 nick2 &lt;bugs@company.xx&gt;
 nick2 &lt;nick2@company.xx&gt;
 santa &lt;me@company.xx&gt;
 claus &lt;me@company.xx&gt;
 CTO &lt;cto@coompany.xx&gt;</code></pre>
 </div></div>
 <div class="paragraph"><p>Then you might want a <code>.mailmap</code> file that looks like:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><code>&lt;cto@company.xx&gt; &lt;cto@coompany.xx&gt;
 Some Dude &lt;some@dude.xx&gt; nick1 &lt;bugs@company.xx&gt;
 Other Author &lt;other@author.xx&gt; nick2 &lt;bugs@company.xx&gt;
 Other Author &lt;other@author.xx&gt; &lt;nick2@company.xx&gt;
 Santa Claus &lt;santa.claus@northpole.xx&gt; &lt;me@company.xx&gt;</code></pre>
 </div></div>
 <div class="paragraph"><p>Use hash <em>#</em> for comments that are either on their own line, or after
 the email address.</p></div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="_git">GIT</h2>
 <div class="sectionbody">
 <div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
 </div>
 </div>
 </div>
 <div id="footnotes"><hr /></div>
 <div id="footer">
 <div id="footer-text">
 Last updated
  2020-03-10 08:03:13 PDT
 </div>
 </div>
 </body>
 </html>