The configuration variables in the 'imap' section are described
in gitlink:git-imap-send[1].
-receive.denyNonFastforwads::
+receive.unpackLimit::
+ If the number of objects received in a push is below this
+ limit then the objects will be unpacked into loose object
+ files. However if the number of received objects equals or
+ exceeds this limit then the received pack will be stored as
+ a pack, after adding any missing delta bases. Storing the
+ pack from a push can make the push operation complete faster,
+ especially on slow filesystems.
+
+receive.denyNonFastForwards::
If set to true, git-receive-pack will deny a ref update which is
not a fast forward. Use this to prevent such an update via a push,
even if that push is forced. This configuration variable is
<p>\r
Do not invoke <em>git-unpack-objects</em> on received data, but\r
create a single packfile out of it instead, and store it\r
- in the object database.\r
+ in the object database. If provided twice then the pack is\r
+ locked against repacking.\r
</p>\r
</dd>\r
<dt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 03-Oct-2006 08:41:04 UTC\r
+Last updated 08-Nov-2006 01:33:27 UTC\r
</div>\r
</div>\r
</body>\r
-k::
Do not invoke 'git-unpack-objects' on received data, but
create a single packfile out of it instead, and store it
- in the object database.
+ in the object database. If provided twice then the pack is
+ locked against repacking.
--exec=<git-upload-pack>::
Use this to specify the path to 'git-upload-pack' on the
</div>\r
<h2>SYNOPSIS</h2>\r
<div class="sectionbody">\r
-<p><em>git-index-pack</em> [-o <index-file>] <pack-file></p>\r
+<p><em>git-index-pack</em> [-v] [-o <index-file>] <pack-file>\r
+<em>git-index-pack</em> --stdin [--fix-thin] [--keep] [-v] [-o <index-file>] [<pack-file>]</p>\r
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
<div class="sectionbody">\r
<dl>\r
<dt>\r
+-v\r
+</dt>\r
+<dd>\r
+<p>\r
+ Be verbose about what is going on, including progress status.\r
+</p>\r
+</dd>\r
+<dt>\r
-o <index-file>\r
</dt>\r
<dd>\r
with .pack).\r
</p>\r
</dd>\r
+<dt>\r
+--stdin\r
+</dt>\r
+<dd>\r
+<p>\r
+ When this flag is provided, the pack is read from stdin\r
+ instead and a copy is then written to <pack-file>. If\r
+ <pack-file> is not specified, the pack is written to\r
+ objects/pack/ directory of the current git repository with\r
+ a default name determined from the pack content. If\r
+ <pack-file> is not specified consider using --keep to\r
+ prevent a race condition between this process and\r
+ <a href=":git-repack.html">:git-repack(1)</a> .\r
+</p>\r
+</dd>\r
+<dt>\r
+--fix-thin\r
+</dt>\r
+<dd>\r
+<p>\r
+ It is possible for <a href="git-pack-objects.html">git-pack-objects(1)</a> to build\r
+ "thin" pack, which records objects in deltified form based on\r
+ objects not included in the pack to reduce network traffic.\r
+ Those objects are expected to be present on the receiving end\r
+ and they must be included in the pack for that pack to be self\r
+ contained and indexable. Without this option any attempt to\r
+ index a thin pack will fail. This option only makes sense in\r
+ conjunction with --stdin.\r
+</p>\r
+</dd>\r
+<dt>\r
+--keep\r
+</dt>\r
+<dd>\r
+<p>\r
+ Before moving the index into its final destination\r
+ create an empty .keep file for the associated pack file.\r
+ This option is usually necessary with --stdin to prevent a\r
+ simultaneous <a href="git-repack.html">git-repack(1)</a> process from deleting\r
+ the newly constructed pack and index before refs can be\r
+ updated to use objects contained in the pack.\r
+</p>\r
+</dd>\r
+<dt>\r
+--keep=<em>why</em>\r
+</dt>\r
+<dd>\r
+<p>\r
+ Like --keep create a .keep file before moving the index into\r
+ its final destination, but rather than creating an empty file\r
+ place <em>why</em> followed by an LF into the .keep file. The <em>why</em>\r
+ message can later be searched for within all .keep files to\r
+ locate any which have outlived their usefulness.\r
+</p>\r
+</dd>\r
</dl>\r
</div>\r
+<h2>Note</h2>\r
+<div class="sectionbody">\r
+<p>Once the index has been created, the list of object names is sorted\r
+and the SHA1 hash of that list is printed to stdout. If --stdin was\r
+also used then this is prefixed by either "pack\t", or "keep\t" if a\r
+new .keep file was successfully created. This is useful to remove a\r
+.keep file used as a lock to prevent the race with <a href="git-repack.html">git-repack(1)</a>\r
+mentioned above.</p>\r
+</div>\r
<h2>Author</h2>\r
<div class="sectionbody">\r
<p>Written by Sergey Vlasov <vsu@altlinux.ru></p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 03-Oct-2006 08:41:08 UTC\r
+Last updated 08-Nov-2006 01:33:28 UTC\r
</div>\r
</div>\r
</body>\r
SYNOPSIS
--------
-'git-index-pack' [-o <index-file>] <pack-file>
+'git-index-pack' [-v] [-o <index-file>] <pack-file>
+'git-index-pack' --stdin [--fix-thin] [--keep] [-v] [-o <index-file>] [<pack-file>]
DESCRIPTION
OPTIONS
-------
+-v::
+ Be verbose about what is going on, including progress status.
+
-o <index-file>::
Write the generated pack index into the specified
file. Without this option the name of pack index
fails if the name of packed archive does not end
with .pack).
+--stdin::
+ When this flag is provided, the pack is read from stdin
+ instead and a copy is then written to <pack-file>. If
+ <pack-file> is not specified, the pack is written to
+ objects/pack/ directory of the current git repository with
+ a default name determined from the pack content. If
+ <pack-file> is not specified consider using --keep to
+ prevent a race condition between this process and
+ gitlink::git-repack[1] .
+
+--fix-thin::
+ It is possible for gitlink:git-pack-objects[1] to build
+ "thin" pack, which records objects in deltified form based on
+ objects not included in the pack to reduce network traffic.
+ Those objects are expected to be present on the receiving end
+ and they must be included in the pack for that pack to be self
+ contained and indexable. Without this option any attempt to
+ index a thin pack will fail. This option only makes sense in
+ conjunction with --stdin.
+
+--keep::
+ Before moving the index into its final destination
+ create an empty .keep file for the associated pack file.
+ This option is usually necessary with --stdin to prevent a
+ simultaneous gitlink:git-repack[1] process from deleting
+ the newly constructed pack and index before refs can be
+ updated to use objects contained in the pack.
+
+--keep='why'::
+ Like --keep create a .keep file before moving the index into
+ its final destination, but rather than creating an empty file
+ place 'why' followed by an LF into the .keep file. The 'why'
+ message can later be searched for within all .keep files to
+ locate any which have outlived their usefulness.
+
+
+Note
+----
+
+Once the index has been created, the list of object names is sorted
+and the SHA1 hash of that list is printed to stdout. If --stdin was
+also used then this is prefixed by either "pack\t", or "keep\t" if a
+new .keep file was successfully created. This is useful to remove a
+.keep file used as a lock to prevent the race with gitlink:git-repack[1]
+mentioned above.
+
Author
------
</p>\r
</dd>\r
<dt>\r
+--progress\r
+</dt>\r
+<dd>\r
+<p>\r
+ Progress status is reported on the standard error stream\r
+ by default when it is attached to a terminal, unless -q\r
+ is specified. This flag forces progress status even if\r
+ the standard error stream is not directed to a terminal.\r
+</p>\r
+</dd>\r
+<dt>\r
+--all-progress\r
+</dt>\r
+<dd>\r
+<p>\r
+ When --stdout is specified then progress report is\r
+ displayed during the object count and deltification phases\r
+ but inhibited during the write-out phase. The reason is\r
+ that in some cases the output stream is directly linked\r
+ to another command which may wish to display progress\r
+ status of its own as it processes incoming pack data.\r
+ This flag is like --progress except that it forces progress\r
+ report for the write-out phase as well even if --stdout is\r
+ used.\r
+</p>\r
+</dd>\r
+<dt>\r
-q\r
</dt>\r
<dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 05-Nov-2006 08:59:28 UTC\r
+Last updated 08-Nov-2006 01:33:28 UTC\r
</div>\r
</div>\r
</body>\r
Only create a packed archive if it would contain at
least one object.
+--progress::
+ Progress status is reported on the standard error stream
+ by default when it is attached to a terminal, unless -q
+ is specified. This flag forces progress status even if
+ the standard error stream is not directed to a terminal.
+
+--all-progress::
+ When --stdout is specified then progress report is
+ displayed during the object count and deltification phases
+ but inhibited during the write-out phase. The reason is
+ that in some cases the output stream is directly linked
+ to another command which may wish to display progress
+ status of its own as it processes incoming pack data.
+ This flag is like --progress except that it forces progress
+ report for the write-out phase as well even if --stdout is
+ used.
+
-q::
This flag makes the command not to report its progress
on the standard error stream.
--- /dev/null
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"\r
+ "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">\r
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">\r
+<head>\r
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />\r
+<meta name="generator" content="AsciiDoc 7.0.2" />\r
+<style type="text/css">\r
+/* Debug borders */\r
+p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 {\r
+/*\r
+ border: 1px solid red;\r
+*/\r
+}\r
+\r
+body {\r
+ margin: 1em 5% 1em 5%;\r
+}\r
+\r
+a { color: blue; }\r
+a:visited { color: fuchsia; }\r
+\r
+em {\r
+ font-style: italic;\r
+}\r
+\r
+strong {\r
+ font-weight: bold;\r
+}\r
+\r
+tt {\r
+ color: navy;\r
+}\r
+\r
+h1, h2, h3, h4, h5, h6 {\r
+ color: #527bbd;\r
+ font-family: sans-serif;\r
+ margin-top: 1.2em;\r
+ margin-bottom: 0.5em;\r
+ line-height: 1.3;\r
+}\r
+\r
+h1 {\r
+ border-bottom: 2px solid silver;\r
+}\r
+h2 {\r
+ border-bottom: 2px solid silver;\r
+ padding-top: 0.5em;\r
+}\r
+\r
+div.sectionbody {\r
+ font-family: serif;\r
+ margin-left: 0;\r
+}\r
+\r
+hr {\r
+ border: 1px solid silver;\r
+}\r
+\r
+p {\r
+ margin-top: 0.5em;\r
+ margin-bottom: 0.5em;\r
+}\r
+\r
+pre {\r
+ padding: 0;\r
+ margin: 0;\r
+}\r
+\r
+span#author {\r
+ color: #527bbd;\r
+ font-family: sans-serif;\r
+ font-weight: bold;\r
+ font-size: 1.2em;\r
+}\r
+span#email {\r
+}\r
+span#revision {\r
+ font-family: sans-serif;\r
+}\r
+\r
+div#footer {\r
+ font-family: sans-serif;\r
+ font-size: small;\r
+ border-top: 2px solid silver;\r
+ padding-top: 0.5em;\r
+ margin-top: 4.0em;\r
+}\r
+div#footer-text {\r
+ float: left;\r
+ padding-bottom: 0.5em;\r
+}\r
+div#footer-badges {\r
+ float: right;\r
+ padding-bottom: 0.5em;\r
+}\r
+\r
+div#preamble,\r
+div.tableblock, div.imageblock, div.exampleblock, div.verseblock,\r
+div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,\r
+div.admonitionblock {\r
+ margin-right: 10%;\r
+ margin-top: 1.5em;\r
+ margin-bottom: 1.5em;\r
+}\r
+div.admonitionblock {\r
+ margin-top: 2.5em;\r
+ margin-bottom: 2.5em;\r
+}\r
+\r
+div.content { /* Block element content. */\r
+ padding: 0;\r
+}\r
+\r
+/* Block element titles. */\r
+div.title, caption.title {\r
+ font-family: sans-serif;\r
+ font-weight: bold;\r
+ text-align: left;\r
+ margin-top: 1.0em;\r
+ margin-bottom: 0.5em;\r
+}\r
+div.title + * {\r
+ margin-top: 0;\r
+}\r
+\r
+td div.title:first-child {\r
+ margin-top: 0.0em;\r
+}\r
+div.content div.title:first-child {\r
+ margin-top: 0.0em;\r
+}\r
+div.content + div.title {\r
+ margin-top: 0.0em;\r
+}\r
+\r
+div.sidebarblock > div.content {\r
+ background: #ffffee;\r
+ border: 1px solid silver;\r
+ padding: 0.5em;\r
+}\r
+\r
+div.listingblock > div.content {\r
+ border: 1px solid silver;\r
+ background: #f4f4f4;\r
+ padding: 0.5em;\r
+}\r
+\r
+div.quoteblock > div.content {\r
+ padding-left: 2.0em;\r
+}\r
+div.quoteblock .attribution {\r
+ text-align: right;\r
+}\r
+\r
+div.admonitionblock .icon {\r
+ vertical-align: top;\r
+ font-size: 1.1em;\r
+ font-weight: bold;\r
+ text-decoration: underline;\r
+ color: #527bbd;\r
+ padding-right: 0.5em;\r
+}\r
+div.admonitionblock td.content {\r
+ padding-left: 0.5em;\r
+ border-left: 2px solid silver;\r
+}\r
+\r
+div.exampleblock > div.content {\r
+ border-left: 2px solid silver;\r
+ padding: 0.5em;\r
+}\r
+\r
+div.verseblock div.content {\r
+ white-space: pre;\r
+}\r
+\r
+div.imageblock div.content { padding-left: 0; }\r
+div.imageblock img { border: 1px solid silver; }\r
+span.image img { border-style: none; }\r
+\r
+dl {\r
+ margin-top: 0.8em;\r
+ margin-bottom: 0.8em;\r
+}\r
+dt {\r
+ margin-top: 0.5em;\r
+ margin-bottom: 0;\r
+ font-style: italic;\r
+}\r
+dd > *:first-child {\r
+ margin-top: 0;\r
+}\r
+\r
+ul, ol {\r
+ list-style-position: outside;\r
+}\r
+ol.olist2 {\r
+ list-style-type: lower-alpha;\r
+}\r
+\r
+div.tableblock > table {\r
+ border-color: #527bbd;\r
+ border-width: 3px;\r
+}\r
+thead {\r
+ font-family: sans-serif;\r
+ font-weight: bold;\r
+}\r
+tfoot {\r
+ font-weight: bold;\r
+}\r
+\r
+div.hlist {\r
+ margin-top: 0.8em;\r
+ margin-bottom: 0.8em;\r
+}\r
+td.hlist1 {\r
+ vertical-align: top;\r
+ font-style: italic;\r
+ padding-right: 0.8em;\r
+}\r
+td.hlist2 {\r
+ vertical-align: top;\r
+}\r
+\r
+@media print {\r
+ div#footer-badges { display: none; }\r
+}\r
+include::./stylesheets/xhtml11-manpage.css[]\r
+/* Workarounds for IE6's broken and incomplete CSS2. */\r
+\r
+div.sidebar-content {\r
+ background: #ffffee;\r
+ border: 1px solid silver;\r
+ padding: 0.5em;\r
+}\r
+div.sidebar-title, div.image-title {\r
+ font-family: sans-serif;\r
+ font-weight: bold;\r
+ margin-top: 0.0em;\r
+ margin-bottom: 0.5em;\r
+}\r
+\r
+div.listingblock div.content {\r
+ border: 1px solid silver;\r
+ background: #f4f4f4;\r
+ padding: 0.5em;\r
+}\r
+\r
+div.quoteblock-content {\r
+ padding-left: 2.0em;\r
+}\r
+\r
+div.exampleblock-content {\r
+ border-left: 2px solid silver;\r
+ padding-left: 0.5em;\r
+}\r
+</style>\r
+<title>git-pickaxe(1)</title>\r
+</head>\r
+<body>\r
+<div id="header">\r
+<h1>\r
+git-pickaxe(1) Manual Page\r
+</h1>\r
+<h2>NAME</h2>\r
+<div class="sectionbody">\r
+<p>git-pickaxe -\r
+ Show what revision and author last modified each line of a file\r
+</p>\r
+</div>\r
+</div>\r
+<h2>SYNOPSIS</h2>\r
+<div class="sectionbody">\r
+<div class="verseblock">\r
+<div class="content"><em>git-pickaxe</em> [-c] [-l] [-t] [-f] [-n] [-p] [-L n,m] [-S <revs-file>]\r
+ [-M] [-C] [-C] [--since=<date>] [<rev>] [--] <file></div></div>\r
+</div>\r
+<h2>DESCRIPTION</h2>\r
+<div class="sectionbody">\r
+<p>Annotates each line in the given file with information from the revision which\r
+last modified the line. Optionally, start annotating from the given revision.</p>\r
+<p>Also it can limit the range of lines annotated.</p>\r
+<p>This report doesn't tell you anything about lines which have been deleted or\r
+replaced; you need to use a tool such as <a href="git-diff.html">git-diff(1)</a> or the "pickaxe"\r
+interface briefly mentioned in the following paragraph.</p>\r
+<p>Apart from supporting file annotation, git also supports searching the\r
+development history for when a code snippet occured in a change. This makes it\r
+possible to track when a code snippet was added to a file, moved or copied\r
+between files, and eventually deleted or replaced. It works by searching for\r
+a text string in the diff. A small example:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ git log --pretty=oneline -S'blame_usage'\r
+5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>\r
+ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output</tt></pre>\r
+</div></div>\r
+</div>\r
+<h2>OPTIONS</h2>\r
+<div class="sectionbody">\r
+<dl>\r
+<dt>\r
+-c, --compatibility\r
+</dt>\r
+<dd>\r
+<p>\r
+ Use the same output mode as <a href="git-annotate.html">git-annotate(1)</a> (Default: off).\r
+</p>\r
+</dd>\r
+<dt>\r
+-L n,m\r
+</dt>\r
+<dd>\r
+<p>\r
+ Annotate only the specified line range (lines count from 1).\r
+</p>\r
+</dd>\r
+<dt>\r
+-l, --long\r
+</dt>\r
+<dd>\r
+<p>\r
+ Show long rev (Default: off).\r
+</p>\r
+</dd>\r
+<dt>\r
+-t, --time\r
+</dt>\r
+<dd>\r
+<p>\r
+ Show raw timestamp (Default: off).\r
+</p>\r
+</dd>\r
+<dt>\r
+-S, --rev-file <revs-file>\r
+</dt>\r
+<dd>\r
+<p>\r
+ Use revs from revs-file instead of calling <a href="git-rev-list.html">git-rev-list(1)</a>.\r
+</p>\r
+</dd>\r
+<dt>\r
+-f, --show-name\r
+</dt>\r
+<dd>\r
+<p>\r
+ Show filename in the original commit. By default\r
+ filename is shown if there is any line that came from a\r
+ file with different name, due to rename detection.\r
+</p>\r
+</dd>\r
+<dt>\r
+-n, --show-number\r
+</dt>\r
+<dd>\r
+<p>\r
+ Show line number in the original commit (Default: off).\r
+</p>\r
+</dd>\r
+<dt>\r
+-p, --porcelain\r
+</dt>\r
+<dd>\r
+<p>\r
+ Show in a format designed for machine consumption.\r
+</p>\r
+</dd>\r
+<dt>\r
+-M\r
+</dt>\r
+<dd>\r
+<p>\r
+ Detect moving lines in the file as well. When a commit\r
+ moves a block of lines in a file (e.g. the original file\r
+ has A and then B, and the commit changes it to B and\r
+ then A), traditional <em>blame</em> algorithm typically blames\r
+ the lines that were moved up (i.e. B) to the parent and\r
+ assigns blame to the lines that were moved down (i.e. A)\r
+ to the child commit. With this option, both groups of\r
+ lines are blamed on the parent.\r
+</p>\r
+</dd>\r
+<dt>\r
+-C\r
+</dt>\r
+<dd>\r
+<p>\r
+ In addition to <tt>-M</tt>, detect lines copied from other\r
+ files that were modified in the same commit. This is\r
+ useful when you reorganize your program and move code\r
+ around across files. When this option is given twice,\r
+ the command looks for copies from all other files in the\r
+ parent for the commit that creates the file in addition.\r
+</p>\r
+</dd>\r
+<dt>\r
+-h, --help\r
+</dt>\r
+<dd>\r
+<p>\r
+ Show help message.\r
+</p>\r
+</dd>\r
+</dl>\r
+</div>\r
+<h2>THE PORCELAIN FORMAT</h2>\r
+<div class="sectionbody">\r
+<p>In this format, each line is output after a header; the\r
+header at the minumum has the first line which has:</p>\r
+<ul>\r
+<li>\r
+<p>\r
+40-byte SHA-1 of the commit the line is attributed to;\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+the line number of the line in the original file;\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+the line number of the line in the final file;\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+on a line that starts a group of line from a different\r
+ commit than the previous one, the number of lines in this\r
+ group. On subsequent lines this field is absent.\r
+</p>\r
+</li>\r
+</ul>\r
+<p>This header line is followed by the following information\r
+at least once for each commit:</p>\r
+<ul>\r
+<li>\r
+<p>\r
+author name ("author"), email ("author-mail"), time\r
+ ("author-time"), and timezone ("author-tz"); similarly\r
+ for committer.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+filename in the commit the line is attributed to.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+the first line of the commit log message ("summary").\r
+</p>\r
+</li>\r
+</ul>\r
+<p>The contents of the actual line is output after the above\r
+header, prefixed by a TAB. This is to allow adding more\r
+header elements later.</p>\r
+</div>\r
+<h2>SPECIFIYING RANGES</h2>\r
+<div class="sectionbody">\r
+<p>Unlike <tt>git-blame</tt> and <tt>git-annotate</tt> in older git, the extent\r
+of annotation can be limited to both line ranges and revision\r
+ranges. When you are interested in finding the origin for\r
+ll. 40-60 for file <tt>foo</tt>, you can use <tt>-L</tt> option like this:</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>git pickaxe -L 40,60 foo</tt></pre>\r
+</div></div>\r
+<p>When you are not interested in changes older than the version\r
+v2.6.18, or changes older than 3 weeks, you can use revision\r
+range specifiers similar to <tt>git-rev-list</tt>:</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>git pickaxe v2.6.18.. -- foo\r
+git pickaxe --since=3.weeks -- foo</tt></pre>\r
+</div></div>\r
+<p>When revision range specifiers are used to limit the annotation,\r
+lines that have not changed since the range boundary (either the\r
+commit v2.6.18 or the most recent commit that is more than 3\r
+weeks old in the above example) are blamed for that range\r
+boundary commit.</p>\r
+<p>A particularly useful way is to see if an added file have lines\r
+created by copy-and-paste from existing files. Sometimes this\r
+indicates that the developer was being sloppy and did not\r
+refactor the code properly. You can first find the commit that\r
+introduced the file with:</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>git log --diff-filter=A --pretty=short -- foo</tt></pre>\r
+</div></div>\r
+<p>and then annotate the change between the commit and its\r
+parents, using <tt>commit^!</tt> notation:</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>git pickaxe -C -C -f $commit^! -- foo</tt></pre>\r
+</div></div>\r
+</div>\r
+<h2>SEE ALSO</h2>\r
+<div class="sectionbody">\r
+<p><a href="git-blame.html">git-blame(1)</a></p>\r
+</div>\r
+<h2>AUTHOR</h2>\r
+<div class="sectionbody">\r
+<p>Written by Junio C Hamano <junkio@cox.net></p>\r
+</div>\r
+<h2>GIT</h2>\r
+<div class="sectionbody">\r
+<p>Part of the <a href="git.html">git(7)</a> suite</p>\r
+</div>\r
+<div id="footer">\r
+<div id="footer-text">\r
+Last updated 08-Nov-2006 01:33:29 UTC\r
+</div>\r
+</div>\r
+</body>\r
+</html>\r
--- /dev/null
+git-pickaxe(1)
+==============
+
+NAME
+----
+git-pickaxe - Show what revision and author last modified each line of a file
+
+SYNOPSIS
+--------
+[verse]
+'git-pickaxe' [-c] [-l] [-t] [-f] [-n] [-p] [-L n,m] [-S <revs-file>]
+ [-M] [-C] [-C] [--since=<date>] [<rev>] [--] <file>
+
+DESCRIPTION
+-----------
+
+Annotates each line in the given file with information from the revision which
+last modified the line. Optionally, start annotating from the given revision.
+
+Also it can limit the range of lines annotated.
+
+This report doesn't tell you anything about lines which have been deleted or
+replaced; you need to use a tool such as gitlink:git-diff[1] or the "pickaxe"
+interface briefly mentioned in the following paragraph.
+
+Apart from supporting file annotation, git also supports searching the
+development history for when a code snippet occured in a change. This makes it
+possible to track when a code snippet was added to a file, moved or copied
+between files, and eventually deleted or replaced. It works by searching for
+a text string in the diff. A small example:
+
+-----------------------------------------------------------------------------
+$ git log --pretty=oneline -S'blame_usage'
+5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
+ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output
+-----------------------------------------------------------------------------
+
+OPTIONS
+-------
+-c, --compatibility::
+ Use the same output mode as gitlink:git-annotate[1] (Default: off).
+
+-L n,m::
+ Annotate only the specified line range (lines count from 1).
+
+-l, --long::
+ Show long rev (Default: off).
+
+-t, --time::
+ Show raw timestamp (Default: off).
+
+-S, --rev-file <revs-file>::
+ Use revs from revs-file instead of calling gitlink:git-rev-list[1].
+
+-f, --show-name::
+ Show filename in the original commit. By default
+ filename is shown if there is any line that came from a
+ file with different name, due to rename detection.
+
+-n, --show-number::
+ Show line number in the original commit (Default: off).
+
+-p, --porcelain::
+ Show in a format designed for machine consumption.
+
+-M::
+ Detect moving lines in the file as well. When a commit
+ moves a block of lines in a file (e.g. the original file
+ has A and then B, and the commit changes it to B and
+ then A), traditional 'blame' algorithm typically blames
+ the lines that were moved up (i.e. B) to the parent and
+ assigns blame to the lines that were moved down (i.e. A)
+ to the child commit. With this option, both groups of
+ lines are blamed on the parent.
+
+-C::
+ In addition to `-M`, detect lines copied from other
+ files that were modified in the same commit. This is
+ useful when you reorganize your program and move code
+ around across files. When this option is given twice,
+ the command looks for copies from all other files in the
+ parent for the commit that creates the file in addition.
+
+-h, --help::
+ Show help message.
+
+
+THE PORCELAIN FORMAT
+--------------------
+
+In this format, each line is output after a header; the
+header at the minumum has the first line which has:
+
+- 40-byte SHA-1 of the commit the line is attributed to;
+- the line number of the line in the original file;
+- the line number of the line in the final file;
+- on a line that starts a group of line from a different
+ commit than the previous one, the number of lines in this
+ group. On subsequent lines this field is absent.
+
+This header line is followed by the following information
+at least once for each commit:
+
+- author name ("author"), email ("author-mail"), time
+ ("author-time"), and timezone ("author-tz"); similarly
+ for committer.
+- filename in the commit the line is attributed to.
+- the first line of the commit log message ("summary").
+
+The contents of the actual line is output after the above
+header, prefixed by a TAB. This is to allow adding more
+header elements later.
+
+
+SPECIFIYING RANGES
+------------------
+
+Unlike `git-blame` and `git-annotate` in older git, the extent
+of annotation can be limited to both line ranges and revision
+ranges. When you are interested in finding the origin for
+ll. 40-60 for file `foo`, you can use `-L` option like this:
+
+ git pickaxe -L 40,60 foo
+
+When you are not interested in changes older than the version
+v2.6.18, or changes older than 3 weeks, you can use revision
+range specifiers similar to `git-rev-list`:
+
+ git pickaxe v2.6.18.. -- foo
+ git pickaxe --since=3.weeks -- foo
+
+When revision range specifiers are used to limit the annotation,
+lines that have not changed since the range boundary (either the
+commit v2.6.18 or the most recent commit that is more than 3
+weeks old in the above example) are blamed for that range
+boundary commit.
+
+A particularly useful way is to see if an added file have lines
+created by copy-and-paste from existing files. Sometimes this
+indicates that the developer was being sloppy and did not
+refactor the code properly. You can first find the commit that
+introduced the file with:
+
+ git log --diff-filter=A --pretty=short -- foo
+
+and then annotate the change between the commit and its
+parents, using `commit{caret}!` notation:
+
+ git pickaxe -C -C -f $commit^! -- foo
+
+
+SEE ALSO
+--------
+gitlink:git-blame[1]
+
+AUTHOR
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+GIT
+---
+Part of the gitlink:git[7] suite
</p>\r
</dd>\r
<dt>\r
-receive.denyNonFastforwads\r
+receive.unpackLimit\r
+</dt>\r
+<dd>\r
+<p>\r
+ If the number of objects received in a push is below this\r
+ limit then the objects will be unpacked into loose object\r
+ files. However if the number of received objects equals or\r
+ exceeds this limit then the received pack will be stored as\r
+ a pack, after adding any missing delta bases. Storing the\r
+ pack from a push can make the push operation complete faster,\r
+ especially on slow filesystems.\r
+</p>\r
+</dd>\r
+<dt>\r
+receive.denyNonFastForwards\r
</dt>\r
<dd>\r
<p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 03-Nov-2006 02:39:58 UTC\r
+Last updated 08-Nov-2006 01:33:29 UTC\r
</div>\r
</div>\r
</body>\r
"<tt>r1 r2 --not $(git-merge-base --all r1 r2)</tt>".\r
It it the set of commits that are reachable from either one of\r
<tt>r1</tt> or <tt>r2</tt> but not from both.</p>\r
-<p>Here are a few examples:</p>\r
+<p>Two other shorthands for naming a set that is formed by a commit\r
+and its parent commits exists. <tt>r1^@</tt> notation means all\r
+parents of <tt>r1</tt>. <tt>r1^!</tt> includes commit <tt>r1</tt> but excludes\r
+its all parents.</p>\r
+<p>Here are a handful examples:</p>\r
<div class="literalblock">\r
<div class="content">\r
<pre><tt>D A B D\r
^A G B D\r
^A F B C F\r
G...I C D F G I\r
-^B G I C D F G I</tt></pre>\r
+^B G I C D F G I\r
+F^@ A B C\r
+F^! H D F H</tt></pre>\r
</div></div>\r
</div>\r
<h2>Author</h2>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 26-Oct-2006 08:47:20 UTC\r
+Last updated 08-Nov-2006 01:33:31 UTC\r
</div>\r
</div>\r
</body>\r
It it the set of commits that are reachable from either one of
`r1` or `r2` but not from both.
-Here are a few examples:
+Two other shorthands for naming a set that is formed by a commit
+and its parent commits exists. `r1{caret}@` notation means all
+parents of `r1`. `r1{caret}!` includes commit `r1` but excludes
+its all parents.
+
+Here are a handful examples:
D A B D
D F A B C D F
- ^A G B D
+ ^A G B D
^A F B C F
G...I C D F G I
- ^B G I C D F G I
+ ^B G I C D F G I
+ F^@ A B C
+ F^! H D F H
Author
------
</p>\r
</dd>\r
<dt>\r
+<a href="git-pickaxe.html">git-pickaxe(1)</a>\r
+</dt>\r
+<dd>\r
+<p>\r
+ Find out where each line in a file came from.\r
+</p>\r
+</dd>\r
+<dt>\r
<a href="git-check-ref-format.html">git-check-ref-format(1)</a>\r
</dt>\r
<dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 07-Nov-2006 07:19:03 UTC\r
+Last updated 08-Nov-2006 01:33:31 UTC\r
</div>\r
</div>\r
</body>\r
gitlink:git-blame[1]::
Blame file lines on commits.
+gitlink:git-pickaxe[1]::
+ Find out where each line in a file came from.
+
gitlink:git-check-ref-format[1]::
Make sure ref name is well formed.
projects / git.git / commitdiff