Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Autogenerated HTML docs for v1.8.5.3-321-g14598

  • Loading branch information...
commit bc8d4783cac3c942fc9e8cf2f3eae4aea8cab5cb 1 parent 21bc18b
@gitster authored
View
27 RelNotes/1.8.5.3.txt
@@ -0,0 +1,27 @@
+Git v1.8.5.3 Release Notes
+==========================
+
+Fixes since v1.8.5.2
+--------------------
+
+ * The "--[no-]informative-errors" options to "git daemon" were parsed
+ a bit too loosely, allowing any other string after these option
+ names.
+
+ * A "gc" process running as a different user should be able to stop a
+ new "gc" process from starting.
+
+ * An earlier "clean-up" introduced an unnecessary memory leak to the
+ credential subsystem.
+
+ * "git mv A B/", when B does not exist as a directory, should error
+ out, but it didn't.
+
+ * "git rev-parse <revs> -- <paths>" did not implement the usual
+ disambiguation rules the commands in the "git log" family used in
+ the same way.
+
+ * "git cat-file --batch=", an admittedly useless command, did not
+ behave very well.
+
+Also contains typofixes, documentation updates and trivial code clean-ups.
View
15 RelNotes/1.9.txt
@@ -90,6 +90,10 @@ Foreign interfaces, subsystems and ports.
UI, Workflows & Features
+ * Just like we give a reasonable default for "less" via the LESS
+ environment variable, we now specify a reasonable default for "lv"
+ via the "LV" environment variable when spawning the pager.
+
* Two-level configuration variable names in "branch.*" and "remote.*"
hierarchies, whose variables are predominantly three-level, were
not completed by hitting a <TAB> in bash and zsh completions.
@@ -154,6 +158,13 @@ UI, Workflows & Features
Performance, Internal Implementation, etc.
+ * When parsing a 40-hex string into the object name, the string is
+ checked to see if it can be interpreted as a ref so that a warning
+ can be given for ambiguity. The code kicked in even when the
+ core.warnambiguousrefs is set to false to squelch this warning, in
+ which case the cycles spent to look at the ref namespace were an
+ expensive no-op, as the result was discarded without being used.
+
* The naming convention of the packfiles has been updated; it used to
be based on the enumeration of names of the objects that are
contained in the pack, but now it also depends on how the packed
@@ -197,6 +208,10 @@ Unless otherwise noted, all the fixes since v1.8.5 in the maintenance
track are contained in this release (see the maintenance releases' notes
for details).
+ * The implementation of 'git stash $cmd "stash@{...}"' did not quote
+ the stash argument properly and left it split at IFS whitespace.
+ (merge 2a07e43 ow/stash-with-ifs later to maint).
+
* The "--[no-]informative-errors" options to "git daemon" were parsed
a bit too loosely, allowing any other string after these option
names.
View
4 config.txt
@@ -567,6 +567,10 @@ be passed to the shell by Git, which will translate the final
command to `LESS=FRSX less -+S`. The environment tells the command
to set the `S` option to chop long lines but the command line
resets it to the default to fold long lines.
++
+Likewise, when the `LV` environment variable is unset, Git sets it
+to `-c`. You can override this setting by exporting `LV` with
+another value or setting `core.pager` to `lv +c`.
core.whitespace::
A comma separated list of common whitespace problems to
View
821 git-config.html
414 additions, 407 deletions not shown
View
52 git-mv.html
@@ -3,7 +3,7 @@
<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.8" />
+<meta name="generator" content="AsciiDoc 8.6.6" />
<title>git-mv(1)</title>
<style type="text/css">
/* Shared CSS for AsciiDoc xhtml11 and html5 backends */
@@ -87,15 +87,11 @@
ul > li { color: #aaa; }
ul > li > * { color: black; }
-.monospaced, code, pre {
- font-family: "Courier New", Courier, monospace;
- font-size: inherit;
- color: navy;
+pre {
padding: 0;
margin: 0;
}
-
#author {
color: #527bbd;
font-weight: bold;
@@ -353,7 +349,7 @@
margin-bottom: 0.1em;
}
-div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
+div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
margin-top: 0;
margin-bottom: 0;
}
@@ -411,14 +407,18 @@
span.overline { text-decoration: overline; }
span.line-through { text-decoration: line-through; }
-div.unbreakable { page-break-inside: avoid; }
-
/*
* xhtml11 specific
*
* */
+tt {
+ font-family: monospace;
+ font-size: inherit;
+ color: navy;
+}
+
div.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
@@ -452,6 +452,12 @@
*
* */
+.monospaced {
+ font-family: monospace;
+ font-size: inherit;
+ color: navy;
+}
+
table.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
@@ -531,8 +537,6 @@
@media print {
body.manpage div#toc { display: none; }
}
-
-
</style>
<script type="text/javascript">
/*<![CDATA[*/
@@ -577,7 +581,7 @@
function tocEntries(el, toclevels) {
var result = new Array;
- var re = new RegExp('[hH]([1-'+(toclevels+1)+'])');
+ var re = new RegExp('[hH]([2-'+(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).
@@ -606,7 +610,7 @@
var i;
for (i = 0; i < toc.childNodes.length; i++) {
var entry = toc.childNodes[i];
- if (entry.nodeName.toLowerCase() == 'div'
+ if (entry.nodeName == 'div'
&& entry.getAttribute("class")
&& entry.getAttribute("class").match(/^toclevel/))
tocEntriesToRemove.push(entry);
@@ -652,7 +656,7 @@
var entriesToRemove = [];
for (i = 0; i < noteholder.childNodes.length; i++) {
var entry = noteholder.childNodes[i];
- if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote")
+ if (entry.nodeName == 'div' && entry.getAttribute("class") == "footnote")
entriesToRemove.push(entry);
}
for (i = 0; i < entriesToRemove.length; i++) {
@@ -757,8 +761,8 @@ <h2 id="_description">DESCRIPTION</h2>
<div class="paragraph"><p>Move or rename a file, directory or symlink.</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>git mv [-v] [-f] [-n] [-k] &lt;source&gt; &lt;destination&gt;
-git mv [-v] [-f] [-n] [-k] &lt;source&gt; ... &lt;destination directory&gt;</code></pre>
+<pre><tt>git mv [-v] [-f] [-n] [-k] &lt;source&gt; &lt;destination&gt;
+git mv [-v] [-f] [-n] [-k] &lt;source&gt; ... &lt;destination directory&gt;</tt></pre>
</div></div>
<div class="paragraph"><p>In the first form, it renames &lt;source&gt;, which must exist and be either
a file, symlink or directory, to &lt;destination&gt;.
@@ -830,6 +834,20 @@ <h2 id="_submodules">SUBMODULES</h2>
</div>
</div>
<div class="sect1">
+<h2 id="_bugs">BUGS</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>Each time a superproject update moves a populated submodule (e.g. when
+switching between commits before and after the move) a stale submodule
+checkout will remain in the old location and an empty directory will
+appear in the new location. To populate the submodule again in the new
+location the user will have to run "git submodule update"
+afterwards. Removing the old directory is only safe when it uses a
+gitfile, as otherwise the history of the submodule will be deleted
+too. Both steps will be obsolete when recursive submodule update has
+been implemented.</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>
@@ -839,7 +857,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-09-09 15:34:20 PDT
+Last updated 2014-01-13 15:35:15 PST
</div>
</div>
</body>
View
12 git-mv.txt
@@ -52,6 +52,18 @@ core.worktree setting to make the submodule work in the new location.
It also will attempt to update the submodule.<name>.path setting in
the linkgit:gitmodules[5] file and stage that file (unless -n is used).
+BUGS
+----
+Each time a superproject update moves a populated submodule (e.g. when
+switching between commits before and after the move) a stale submodule
+checkout will remain in the old location and an empty directory will
+appear in the new location. To populate the submodule again in the new
+location the user will have to run "git submodule update"
+afterwards. Removing the old directory is only safe when it uses a
+gitfile, as otherwise the history of the submodule will be deleted
+too. Both steps will be obsolete when recursive submodule update has
+been implemented.
+
GIT
---
Part of the linkgit:git[1] suite
View
101 git-rm.html
@@ -3,7 +3,7 @@
<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.8" />
+<meta name="generator" content="AsciiDoc 8.6.6" />
<title>git-rm(1)</title>
<style type="text/css">
/* Shared CSS for AsciiDoc xhtml11 and html5 backends */
@@ -87,15 +87,11 @@
ul > li { color: #aaa; }
ul > li > * { color: black; }
-.monospaced, code, pre {
- font-family: "Courier New", Courier, monospace;
- font-size: inherit;
- color: navy;
+pre {
padding: 0;
margin: 0;
}
-
#author {
color: #527bbd;
font-weight: bold;
@@ -353,7 +349,7 @@
margin-bottom: 0.1em;
}
-div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
+div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
margin-top: 0;
margin-bottom: 0;
}
@@ -411,14 +407,18 @@
span.overline { text-decoration: overline; }
span.line-through { text-decoration: line-through; }
-div.unbreakable { page-break-inside: avoid; }
-
/*
* xhtml11 specific
*
* */
+tt {
+ font-family: monospace;
+ font-size: inherit;
+ color: navy;
+}
+
div.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
@@ -452,6 +452,12 @@
*
* */
+.monospaced {
+ font-family: monospace;
+ font-size: inherit;
+ color: navy;
+}
+
table.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
@@ -531,8 +537,6 @@
@media print {
body.manpage div#toc { display: none; }
}
-
-
</style>
<script type="text/javascript">
/*<![CDATA[*/
@@ -577,7 +581,7 @@
function tocEntries(el, toclevels) {
var result = new Array;
- var re = new RegExp('[hH]([1-'+(toclevels+1)+'])');
+ var re = new RegExp('[hH]([2-'+(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).
@@ -606,7 +610,7 @@
var i;
for (i = 0; i < toc.childNodes.length; i++) {
var entry = toc.childNodes[i];
- if (entry.nodeName.toLowerCase() == 'div'
+ if (entry.nodeName == 'div'
&& entry.getAttribute("class")
&& entry.getAttribute("class").match(/^toclevel/))
tocEntriesToRemove.push(entry);
@@ -652,7 +656,7 @@
var entriesToRemove = [];
for (i = 0; i < noteholder.childNodes.length; i++) {
var entry = noteholder.childNodes[i];
- if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote")
+ if (entry.nodeName == 'div' && entry.getAttribute("class") == "footnote")
entriesToRemove.push(entry);
}
for (i = 0; i < entriesToRemove.length; i++) {
@@ -755,13 +759,13 @@ <h2 id="_synopsis">SYNOPSIS</h2>
<h2 id="_description">DESCRIPTION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Remove files from the index, or from the working tree and the index.
-<code>git rm</code> will not remove a file from just your working directory.
+<tt>git rm</tt> will not remove a file from just your working directory.
(There is no option to remove a file only from the working tree
-and yet keep it in the index; use <code>/bin/rm</code> if you want to do that.)
+and yet keep it in the index; use <tt>/bin/rm</tt> if you want to do that.)
The files being removed have to be identical to the tip of the branch,
and no updates to their contents can be staged in the index,
-though that default behavior can be overridden with the <code>-f</code> option.
-When <code>--cached</code> is given, the staged content has to
+though that default behavior can be overridden with the <tt>-f</tt> option.
+When <tt>--cached</tt> is given, the staged content has to
match either the tip of the branch or the file on disk,
allowing the file to be removed from just the index.</p></div>
</div>
@@ -775,14 +779,14 @@ <h2 id="_options">OPTIONS</h2>
</dt>
<dd>
<p>
- Files to remove. Fileglobs (e.g. <code>*.c</code>) can be given to
+ Files to remove. Fileglobs (e.g. <tt>*.c</tt>) can be given to
remove all matching files. If you want Git to expand
file glob characters, you may need to shell-escape them.
A leading directory name
- (e.g. <code>dir</code> to remove <code>dir/file1</code> and <code>dir/file2</code>) can be
+ (e.g. <tt>dir</tt> to remove <tt>dir/file1</tt> and <tt>dir/file2</tt>) can be
given to remove all files in the directory, and recursively
all sub-directories,
- but this requires the <code>-r</code> option to be explicitly given.
+ but this requires the <tt>-r</tt> option to be explicitly given.
</p>
</dd>
<dt class="hdlist1">
@@ -854,7 +858,7 @@ <h2 id="_options">OPTIONS</h2>
</dt>
<dd>
<p>
- <code>git rm</code> normally outputs one line (in the form of an <code>rm</code> command)
+ <tt>git rm</tt> normally outputs one line (in the form of an <tt>rm</tt> command)
for each file removed. This option suppresses that output.
</p>
</dd>
@@ -869,15 +873,15 @@ <h2 id="_discussion">DISCUSSION</h2>
removes only the paths that are known to Git. Giving the name of
a file that you have not told Git about does not remove that file.</p></div>
<div class="paragraph"><p>File globbing matches across directory boundaries. Thus, given
-two directories <code>d</code> and <code>d2</code>, there is a difference between
-using <code>git rm 'd*'</code> and <code>git rm 'd/*'</code>, as the former will
-also remove all of directory <code>d2</code>.</p></div>
+two directories <tt>d</tt> and <tt>d2</tt>, there is a difference between
+using <tt>git rm 'd*'</tt> and <tt>git rm 'd/*'</tt>, as the former will
+also remove all of directory <tt>d2</tt>.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_removing_files_that_have_disappeared_from_the_filesystem">REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM</h2>
<div class="sectionbody">
-<div class="paragraph"><p>There is no option for <code>git rm</code> to remove from the index only
+<div class="paragraph"><p>There is no option for <tt>git rm</tt> to remove from the index only
the paths that have disappeared from the filesystem. However,
depending on the use case, there are several ways that can be
done.</p></div>
@@ -885,10 +889,10 @@ <h2 id="_removing_files_that_have_disappeared_from_the_filesystem">REMOVING FILE
<h3 id="_using_8220_git_commit_a_8221">Using &#8220;git commit -a&#8221;</h3>
<div class="paragraph"><p>If you intend that your next commit should record all modifications
of tracked files in the working tree and record all removals of
-files that have been removed from the working tree with <code>rm</code>
-(as opposed to <code>git rm</code>), use <code>git commit -a</code>, as it will
+files that have been removed from the working tree with <tt>rm</tt>
+(as opposed to <tt>git rm</tt>), use <tt>git commit -a</tt>, as it will
automatically notice and record all removals. You can also have a
-similar effect without committing by using <code>git add -u</code>.</p></div>
+similar effect without committing by using <tt>git add -u</tt>.</p></div>
</div>
<div class="sect2">
<h3 id="_using_8220_git_add_a_8221">Using &#8220;git add -A&#8221;</h3>
@@ -899,7 +903,7 @@ <h3 id="_using_8220_git_add_a_8221">Using &#8220;git add -A&#8221;</h3>
tree using this command:</p></div>
<div class="listingblock">
<div class="content">
-<pre><code>git ls-files -z | xargs -0 rm -f</code></pre>
+<pre><tt>git ls-files -z | xargs -0 rm -f</tt></pre>
</div></div>
<div class="paragraph"><p>and then untar the new code in the working tree. Alternately
you could <em>rsync</em> the changes into the working tree.</p></div>
@@ -907,7 +911,7 @@ <h3 id="_using_8220_git_add_a_8221">Using &#8220;git add -A&#8221;</h3>
modifications in the working tree is:</p></div>
<div class="listingblock">
<div class="content">
-<pre><code>git add -A</code></pre>
+<pre><tt>git add -A</tt></pre>
</div></div>
<div class="paragraph"><p>See <a href="git-add.html">git-add(1)</a>.</p></div>
</div>
@@ -915,11 +919,11 @@ <h3 id="_using_8220_git_add_a_8221">Using &#8220;git add -A&#8221;</h3>
<h3 id="_other_ways">Other ways</h3>
<div class="paragraph"><p>If all you really want to do is to remove from the index the files
that are no longer present in the working tree (perhaps because
-your working tree is dirty so that you cannot use <code>git commit -a</code>),
+your working tree is dirty so that you cannot use <tt>git commit -a</tt>),
use the following command:</p></div>
<div class="listingblock">
<div class="content">
-<pre><code>git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached</code></pre>
+<pre><tt>git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached</tt></pre>
</div></div>
</div>
</div>
@@ -931,7 +935,7 @@ <h2 id="_submodules">SUBMODULES</h2>
with a Git version 1.7.8 or newer) will be removed from the work
tree, as their repository lives inside the .git directory of the
superproject. If a submodule (or one of those nested inside it)
-still uses a .git directory, <code>git rm</code> will fail - no matter if forced
+still uses a .git directory, <tt>git rm</tt> will fail - no matter if forced
or not - to protect the submodule&#8217;s history. If it exists the
submodule.&lt;name&gt; section in the <a href="gitmodules.html">gitmodules(5)</a> file will also
be removed and that file will be staged (unless --cached or -n are used).</p></div>
@@ -942,7 +946,7 @@ <h2 id="_submodules">SUBMODULES</h2>
tree from being removed.</p></div>
<div class="paragraph"><p>If you only want to remove the local checkout of a submodule from your
work tree without committing the removal,
-use <a href="git-submodule.html">git-submodule(1)</a> <code>deinit</code> instead.</p></div>
+use <a href="git-submodule.html">git-submodule(1)</a> <tt>deinit</tt> instead.</p></div>
</div>
</div>
<div class="sect1">
@@ -950,31 +954,42 @@ <h2 id="_examples">EXAMPLES</h2>
<div class="sectionbody">
<div class="dlist"><dl>
<dt class="hdlist1">
-<code>git rm Documentation/\*.txt</code>
+<tt>git rm Documentation/\*.txt</tt>
</dt>
<dd>
<p>
- Removes all <code>*.txt</code> files from the index that are under the
- <code>Documentation</code> directory and any of its subdirectories.
+ Removes all <tt>*.txt</tt> files from the index that are under the
+ <tt>Documentation</tt> directory and any of its subdirectories.
</p>
-<div class="paragraph"><p>Note that the asterisk <code>*</code> is quoted from the shell in this
+<div class="paragraph"><p>Note that the asterisk <tt>*</tt> is quoted from the shell in this
example; this lets Git, and not the shell, expand the pathnames
-of files and subdirectories under the <code>Documentation/</code> directory.</p></div>
+of files and subdirectories under the <tt>Documentation/</tt> directory.</p></div>
</dd>
<dt class="hdlist1">
-<code>git rm -f git-*.sh</code>
+<tt>git rm -f git-*.sh</tt>
</dt>
<dd>
<p>
Because this example lets the shell expand the asterisk
(i.e. you are listing the files explicitly), it
- does not remove <code>subdir/git-foo.sh</code>.
+ does not remove <tt>subdir/git-foo.sh</tt>.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
+<h2 id="_bugs">BUGS</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>Each time a superproject update removes a populated submodule
+(e.g. when switching between commits before and after the removal) a
+stale submodule checkout will remain in the old location. Removing the
+old directory is only safe when it uses a gitfile, as otherwise the
+history of the submodule will be deleted too. This step will be
+obsolete when recursive submodule update has been implemented.</p></div>
+</div>
+</div>
+<div class="sect1">
<h2 id="_see_also">SEE ALSO</h2>
<div class="sectionbody">
<div class="paragraph"><p><a href="git-add.html">git-add(1)</a></p></div>
@@ -990,7 +1005,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-09-09 15:34:20 PDT
+Last updated 2014-01-13 15:35:15 PST
</div>
</div>
</body>
View
9 git-rm.txt
@@ -170,6 +170,15 @@ of files and subdirectories under the `Documentation/` directory.
(i.e. you are listing the files explicitly), it
does not remove `subdir/git-foo.sh`.
+BUGS
+----
+Each time a superproject update removes a populated submodule
+(e.g. when switching between commits before and after the removal) a
+stale submodule checkout will remain in the old location. Removing the
+old directory is only safe when it uses a gitfile, as otherwise the
+history of the submodule will be deleted too. This step will be
+obsolete when recursive submodule update has been implemented.
+
SEE ALSO
--------
linkgit:git-add[1]
View
140 git.html
@@ -3,7 +3,7 @@
<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.8" />
+<meta name="generator" content="AsciiDoc 8.6.6" />
<title>git(1)</title>
<style type="text/css">
/* Shared CSS for AsciiDoc xhtml11 and html5 backends */
@@ -87,15 +87,11 @@
ul > li { color: #aaa; }
ul > li > * { color: black; }
-.monospaced, code, pre {
- font-family: "Courier New", Courier, monospace;
- font-size: inherit;
- color: navy;
+pre {
padding: 0;
margin: 0;
}
-
#author {
color: #527bbd;
font-weight: bold;
@@ -353,7 +349,7 @@
margin-bottom: 0.1em;
}
-div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
+div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
margin-top: 0;
margin-bottom: 0;
}
@@ -411,14 +407,18 @@
span.overline { text-decoration: overline; }
span.line-through { text-decoration: line-through; }
-div.unbreakable { page-break-inside: avoid; }
-
/*
* xhtml11 specific
*
* */
+tt {
+ font-family: monospace;
+ font-size: inherit;
+ color: navy;
+}
+
div.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
@@ -452,6 +452,12 @@
*
* */
+.monospaced {
+ font-family: monospace;
+ font-size: inherit;
+ color: navy;
+}
+
table.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
@@ -531,8 +537,6 @@
@media print {
body.manpage div#toc { display: none; }
}
-
-
</style>
<script type="text/javascript">
/*<![CDATA[*/
@@ -577,7 +581,7 @@
function tocEntries(el, toclevels) {
var result = new Array;
- var re = new RegExp('[hH]([1-'+(toclevels+1)+'])');
+ var re = new RegExp('[hH]([2-'+(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).
@@ -606,7 +610,7 @@
var i;
for (i = 0; i < toc.childNodes.length; i++) {
var entry = toc.childNodes[i];
- if (entry.nodeName.toLowerCase() == 'div'
+ if (entry.nodeName == 'div'
&& entry.getAttribute("class")
&& entry.getAttribute("class").match(/^toclevel/))
tocEntriesToRemove.push(entry);
@@ -652,7 +656,7 @@
var entriesToRemove = [];
for (i = 0; i < noteholder.childNodes.length; i++) {
var entry = noteholder.childNodes[i];
- if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote")
+ if (entry.nodeName == 'div' && entry.getAttribute("class") == "footnote")
entriesToRemove.push(entry);
}
for (i = 0; i < entriesToRemove.length; i++) {
@@ -770,7 +774,7 @@ <h2 id="_description">DESCRIPTION</h2>
individual Git commands with "git help command". <a href="gitcli.html">gitcli(7)</a>
manual page gives you an overview of the command line command syntax.</p></div>
<div class="paragraph"><p>Formatted and hyperlinked version of the latest Git documentation
-can be viewed at <code>http://git-htmldocs.googlecode.com/git/git.html</code>.</p></div>
+can be viewed at <tt>http://git-htmldocs.googlecode.com/git/git.html</tt>.</p></div>
</div>
</div>
<div class="sect1">
@@ -797,8 +801,8 @@ <h2 id="_options">OPTIONS</h2>
</p>
<div class="paragraph"><p>Other options are available to control how the manual page is
displayed. See <a href="git-help.html">git-help(1)</a> for more information,
-because <code>git --help ...</code> is converted internally into <code>git
-help ...</code>.</p></div>
+because <tt>git --help ...</tt> is converted internally into <tt>git
+help ...</tt>.</p></div>
</dd>
<dt class="hdlist1">
-C &lt;path&gt;
@@ -806,18 +810,18 @@ <h2 id="_options">OPTIONS</h2>
<dd>
<p>
Run as if git was started in <em>&lt;path&gt;</em> instead of the current working
- directory. When multiple <code>-C</code> options are given, each subsequent
- non-absolute <code>-C &lt;path&gt;</code> is interpreted relative to the preceding <code>-C
- &lt;path&gt;</code>.
+ directory. When multiple <tt>-C</tt> options are given, each subsequent
+ non-absolute <tt>-C &lt;path&gt;</tt> is interpreted relative to the preceding <tt>-C
+ &lt;path&gt;</tt>.
</p>
-<div class="paragraph"><p>This option affects options that expect path name like <code>--git-dir</code> and
-<code>--work-tree</code> in that their interpretations of the path names would be
-made relative to the working directory caused by the <code>-C</code> option. For
+<div class="paragraph"><p>This option affects options that expect path name like <tt>--git-dir</tt> and
+<tt>--work-tree</tt> in that their interpretations of the path names would be
+made relative to the working directory caused by the <tt>-C</tt> option. For
example the following invocations are equivalent:</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>git --git-dir=a.git --work-tree=b -C c status
-git --git-dir=c/a.git --work-tree=c/b status</code></pre>
+<pre><tt>git --git-dir=a.git --work-tree=b -C c status
+git --git-dir=c/a.git --work-tree=c/b status</tt></pre>
</div></div>
</dd>
<dt class="hdlist1">
@@ -856,7 +860,7 @@ <h2 id="_options">OPTIONS</h2>
</dt>
<dd>
<p>
- Print the manpath (see <code>man(1)</code>) for the man pages for
+ Print the manpath (see <tt>man(1)</tt>) for the man pages for
this version of Git and exit.
</p>
</dd>
@@ -878,7 +882,7 @@ <h2 id="_options">OPTIONS</h2>
<dd>
<p>
Pipe all output into <em>less</em> (or if set, $PAGER) if standard
- output is a terminal. This overrides the <code>pager.&lt;cmd&gt;</code>
+ output is a terminal. This overrides the <tt>pager.&lt;cmd&gt;</tt>
configuration options (see the "Configuration Mechanism" section
below).
</p>
@@ -920,7 +924,7 @@ <h2 id="_options">OPTIONS</h2>
<dd>
<p>
Set the Git namespace. See <a href="gitnamespaces.html">gitnamespaces(7)</a> for more
- details. Equivalent to setting the <code>GIT_NAMESPACE</code> environment
+ details. Equivalent to setting the <tt>GIT_NAMESPACE</tt> environment
variable.
</p>
</dd>
@@ -949,8 +953,8 @@ <h2 id="_options">OPTIONS</h2>
<dd>
<p>
Treat pathspecs literally (i.e. no globbing, no pathspec magic).
- This is equivalent to setting the <code>GIT_LITERAL_PATHSPECS</code> environment
- variable to <code>1</code>.
+ This is equivalent to setting the <tt>GIT_LITERAL_PATHSPECS</tt> environment
+ variable to <tt>1</tt>.
</p>
</dd>
<dt class="hdlist1">
@@ -959,7 +963,7 @@ <h2 id="_options">OPTIONS</h2>
<dd>
<p>
Add "glob" magic to all pathspec. This is equivalent to setting
- the <code>GIT_GLOB_PATHSPECS</code> environment variable to <code>1</code>. Disabling
+ the <tt>GIT_GLOB_PATHSPECS</tt> environment variable to <tt>1</tt>. Disabling
globbing on individual pathspecs can be done using pathspec
magic ":(literal)"
</p>
@@ -970,7 +974,7 @@ <h2 id="_options">OPTIONS</h2>
<dd>
<p>
Add "literal" magic to all pathspec. This is equivalent to setting
- the <code>GIT_NOGLOB_PATHSPECS</code> environment variable to <code>1</code>. Enabling
+ the <tt>GIT_NOGLOB_PATHSPECS</tt> environment variable to <tt>1</tt>. Enabling
globbing on individual pathspecs can be done using pathspec
magic ":(glob)"
</p>
@@ -981,7 +985,7 @@ <h2 id="_options">OPTIONS</h2>
<dd>
<p>
Add "icase" magic to all pathspec. This is equivalent to setting
- the <code>GIT_ICASE_PATHSPECS</code> environment variable to <code>1</code>.
+ the <tt>GIT_ICASE_PATHSPECS</tt> environment variable to <tt>1</tt>.
</p>
</dd>
</dl></div>
@@ -2175,7 +2179,7 @@ <h2 id="_configuration_mechanism">Configuration Mechanism</h2>
like this:</p></div>
<div class="listingblock">
<div class="content">
-<pre><code>#
+<pre><tt>#
# A '#' or ';' character indicates a comment.
#
@@ -2187,7 +2191,7 @@ <h2 id="_configuration_mechanism">Configuration Mechanism</h2>
; user identity
[user]
name = "Junio C Hamano"
- email = "gitster@pobox.com"</code></pre>
+ email = "gitster@pobox.com"</tt></pre>
</div></div>
<div class="paragraph"><p>Various commands read from the configuration file and adjust
their operation accordingly. See <a href="git-config.html">git-config(1)</a> for a
@@ -2258,7 +2262,7 @@ <h2 id="_identifier_terminology">Identifier Terminology</h2>
<dd>
<p>
Indicates that an object type is required.
- Currently one of: <code>blob</code>, <code>tree</code>, <code>commit</code>, or <code>tag</code>.
+ Currently one of: <tt>blob</tt>, <tt>tree</tt>, <tt>commit</tt>, or <tt>tag</tt>.
</p>
</dd>
<dt class="hdlist1">
@@ -2267,7 +2271,7 @@ <h2 id="_identifier_terminology">Identifier Terminology</h2>
<dd>
<p>
Indicates a filename - almost always relative to the
- root of the tree structure <code>GIT_INDEX_FILE</code> describes.
+ root of the tree structure <tt>GIT_INDEX_FILE</tt> describes.
</p>
</dd>
</dl></div>
@@ -2293,7 +2297,7 @@ <h2 id="_symbolic_identifiers">Symbolic Identifiers</h2>
<dd>
<p>
a valid tag <em>name</em>
- (i.e. a <code>refs/tags/&lt;tag&gt;</code> reference).
+ (i.e. a <tt>refs/tags/&lt;tag&gt;</tt> reference).
</p>
</dd>
<dt class="hdlist1">
@@ -2302,7 +2306,7 @@ <h2 id="_symbolic_identifiers">Symbolic Identifiers</h2>
<dd>
<p>
a valid head <em>name</em>
- (i.e. a <code>refs/heads/&lt;head&gt;</code> reference).
+ (i.e. a <tt>refs/heads/&lt;head&gt;</tt> reference).
</p>
</dd>
</dl></div>
@@ -2316,7 +2320,7 @@ <h2 id="_file_directory_structure">File/Directory Structure</h2>
<div class="paragraph"><p>Please see the <a href="gitrepository-layout.html">gitrepository-layout(5)</a> document.</p></div>
<div class="paragraph"><p>Read <a href="githooks.html">githooks(5)</a> for more details about each hook.</p></div>
<div class="paragraph"><p>Higher level SCMs may provide and manage additional information in the
-<code>$GIT_DIR</code>.</p></div>
+<tt>$GIT_DIR</tt>.</p></div>
</div>
</div>
<div class="sect1">
@@ -2341,7 +2345,7 @@ <h3 id="_the_git_repository">The Git Repository</h3>
<dd>
<p>
This environment allows the specification of an alternate
- index file. If not specified, the default of <code>$GIT_DIR/index</code>
+ index file. If not specified, the default of <tt>$GIT_DIR/index</tt>
is used.
</p>
</dd>
@@ -2352,7 +2356,7 @@ <h3 id="_the_git_repository">The Git Repository</h3>
<p>
If the object storage directory is specified via this
environment variable then the sha1 directories are created
- underneath - otherwise the default <code>$GIT_DIR/objects</code>
+ underneath - otherwise the default <tt>$GIT_DIR/objects</tt>
directory is used.
</p>
</dd>
@@ -2374,7 +2378,7 @@ <h3 id="_the_git_repository">The Git Repository</h3>
<dd>
<p>
If the <em>GIT_DIR</em> environment variable is set then it
- specifies a path to use instead of the default <code>.git</code>
+ specifies a path to use instead of the default <tt>.git</tt>
for the base of the repository.
The <em>--git-dir</em> command-line option also sets this value.
</p>
@@ -2492,7 +2496,7 @@ <h3 id="_git_diffs">Git Diffs</h3>
</p>
<div class="literalblock">
<div class="content">
-<pre><code>path old-file old-hex old-mode new-file new-hex new-mode</code></pre>
+<pre><tt>path old-file old-hex old-mode new-file new-hex new-mode</tt></pre>
</div></div>
<div class="paragraph"><p>where:</p></div>
</dd>
@@ -2521,8 +2525,8 @@ <h3 id="_git_diffs">Git Diffs</h3>
are the octal representation of the file modes.
</p>
<div class="paragraph"><p>The file parameters can point at the user&#8217;s working file
-(e.g. <code>new-file</code> in "git-diff-files"), <code>/dev/null</code> (e.g. <code>old-file</code>
-when a new file is added), or a temporary file (e.g. <code>old-file</code> in the
+(e.g. <tt>new-file</tt> in "git-diff-files"), <tt>/dev/null</tt> (e.g. <tt>old-file</tt>
+when a new file is added), or a temporary file (e.g. <tt>old-file</tt> in the
index). <em>GIT_EXTERNAL_DIFF</em> should not worry about unlinking the
temporary file --- it is removed when <em>GIT_EXTERNAL_DIFF</em> exits.</p></div>
<div class="paragraph"><p>For a path that is unmerged, <em>GIT_EXTERNAL_DIFF</em> is called with 1
@@ -2566,9 +2570,9 @@ <h3 id="_other">other</h3>
</dt>
<dd>
<p>
- This environment variable overrides <code>$PAGER</code>. If it is set
+ This environment variable overrides <tt>$PAGER</tt>. If it is set
to an empty string or to the value "cat", Git will not launch
- a pager. See also the <code>core.pager</code> option in
+ a pager. See also the <tt>core.pager</tt> option in
<a href="git-config.html">git-config(1)</a>.
</p>
</dd>
@@ -2577,10 +2581,10 @@ <h3 id="_other">other</h3>
</dt>
<dd>
<p>
- This environment variable overrides <code>$EDITOR</code> and <code>$VISUAL</code>.
+ This environment variable overrides <tt>$EDITOR</tt> and <tt>$VISUAL</tt>.
It is used by several Git commands when, on interactive mode,
an editor is to be launched. See also <a href="git-var.html">git-var(1)</a>
- and the <code>core.editor</code> option in <a href="git-config.html">git-config(1)</a>.
+ and the <tt>core.editor</tt> option in <a href="git-config.html">git-config(1)</a>.
</p>
</dd>
<dt class="hdlist1">
@@ -2602,7 +2606,7 @@ <h3 id="_other">other</h3>
you will need to wrap the program and options into a shell script,
then set GIT_SSH to refer to the shell script.</p></div>
<div class="paragraph"><p>Usually it is easier to configure any desired options through your
-personal <code>.ssh/config</code> file. Please consult your ssh documentation
+personal <tt>.ssh/config</tt> file. Please consult your ssh documentation
for further details.</p></div>
</dd>
<dt class="hdlist1">
@@ -2623,10 +2627,10 @@ <h3 id="_other">other</h3>
<dd>
<p>
Whether to skip reading settings from the system-wide
- <code>$(prefix)/etc/gitconfig</code> file. This environment variable can
- be used along with <code>$HOME</code> and <code>$XDG_CONFIG_HOME</code> to create a
+ <tt>$(prefix)/etc/gitconfig</tt> file. This environment variable can
+ be used along with <tt>$HOME</tt> and <tt>$XDG_CONFIG_HOME</tt> to create a
predictable environment for a picky script, or you can set it
- temporarily to avoid using a buggy <code>/etc/gitconfig</code> file while
+ temporarily to avoid using a buggy <tt>/etc/gitconfig</tt> file while
waiting for someone with sufficient permissions to fix it.
</p>
</dd>
@@ -2652,7 +2656,7 @@ <h3 id="_other">other</h3>
<dd>
<p>
If this variable is set to "1", "2" or "true" (comparison
- is case insensitive), Git will print <code>trace:</code> messages on
+ is case insensitive), Git will print <tt>trace:</tt> messages on
stderr telling about alias expansion, built-in command
execution and external command execution.
If this variable is set to an integer value greater than 1
@@ -2693,13 +2697,13 @@ <h3 id="_other">other</h3>
</dt>
<dd>
<p>
- Setting this variable to <code>1</code> will cause Git to treat all
+ Setting this variable to <tt>1</tt> will cause Git to treat all
pathspecs literally, rather than as glob patterns. For example,
- running <code>GIT_LITERAL_PATHSPECS=1 git log -- '*.c'</code> will search
- for commits that touch the path <code>*.c</code>, not any paths that the
- glob <code>*.c</code> matches. You might want this if you are feeding
+ running <tt>GIT_LITERAL_PATHSPECS=1 git log -- '*.c'</tt> will search
+ for commits that touch the path <tt>*.c</tt>, not any paths that the
+ glob <tt>*.c</tt> matches. You might want this if you are feeding
literal paths to Git (e.g., paths previously given to you by
- <code>git ls-tree</code>, <code>--raw</code> diff output, etc).
+ <tt>git ls-tree</tt>, <tt>--raw</tt> diff output, etc).
</p>
</dd>
<dt class="hdlist1">
@@ -2707,7 +2711,7 @@ <h3 id="_other">other</h3>
</dt>
<dd>
<p>
- Setting this variable to <code>1</code> will cause Git to treat all
+ Setting this variable to <tt>1</tt> will cause Git to treat all
pathspecs as glob patterns (aka "glob" magic).
</p>
</dd>
@@ -2716,7 +2720,7 @@ <h3 id="_other">other</h3>
</dt>
<dd>
<p>
- Setting this variable to <code>1</code> will cause Git to treat all
+ Setting this variable to <tt>1</tt> will cause Git to treat all
pathspecs as literal (aka "literal" magic).
</p>
</dd>
@@ -2725,7 +2729,7 @@ <h3 id="_other">other</h3>
</dt>
<dd>
<p>
- Setting this variable to <code>1</code> will cause Git to treat all
+ Setting this variable to <tt>1</tt> will cause Git to treat all
pathspecs as case-insensitive.
</p>
</dd>
@@ -2739,7 +2743,7 @@ <h3 id="_other">other</h3>
typically the name of the high-level command that updated
the ref), in addition to the old and new values of the ref.
A scripted Porcelain command can use set_reflog_action
- helper function in <code>git-sh-setup</code> to set its name to this
+ helper function in <tt>git-sh-setup</tt> to set its name to this
variable when it is invoked as the top level command by the
end user, to be recorded in the body of the reflog.
</p>
@@ -2777,10 +2781,10 @@ <h2 id="_discussion_a_id_discussion_a">Discussion<a id="Discussion"></a></h2>
efficiency may later be compressed together into "pack files".</p></div>
<div class="paragraph"><p>Named pointers called refs mark interesting points in history. A ref
may contain the SHA-1 name of an object or the name of another ref. Refs
-with names beginning <code>ref/head/</code> contain the SHA-1 name of the most
+with names beginning <tt>ref/head/</tt> contain the SHA-1 name of the most
recent commit (or "head") of a branch under development. SHA-1 names of
-tags of interest are stored under <code>ref/tags/</code>. A special ref named
-<code>HEAD</code> contains the name of the currently checked-out branch.</p></div>
+tags of interest are stored under <tt>ref/tags/</tt>. A special ref named
+<tt>HEAD</tt> contains the name of the currently checked-out branch.</p></div>
<div class="paragraph"><p>The index file is initialized with a list of all paths and, for each
path, a blob object and a set of attributes. The blob object represents
the contents of the file as of the head of the current branch. The
@@ -2852,7 +2856,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-12-27 16:32:55 PST
+Last updated 2014-01-13 15:35:15 PST
</div>
</div>
</body>
View
3  git.txt
@@ -43,9 +43,10 @@ unreleased) version of Git, that is available from 'master'
branch of the `git.git` repository.
Documentation for older releases are available here:
-* link:v1.8.5.2/git.html[documentation for release 1.8.5.2]
+* link:v1.8.5.3/git.html[documentation for release 1.8.5.3]
* release notes for
+ link:RelNotes/1.8.5.3.txt[1.8.5.3],
link:RelNotes/1.8.5.2.txt[1.8.5.2],
link:RelNotes/1.8.5.1.txt[1.8.5.1],
link:RelNotes/1.8.5.txt[1.8.5].
View
336 technical/pack-heuristics.html
@@ -3,8 +3,8 @@
<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.8" />
-<title></title>
+<meta name="generator" content="AsciiDoc 8.6.6" />
+<title>Concerning Git&#8217;s Packing Heuristics</title>
<style type="text/css">
/* Shared CSS for AsciiDoc xhtml11 and html5 backends */
@@ -87,15 +87,11 @@
ul > li { color: #aaa; }
ul > li > * { color: black; }
-.monospaced, code, pre {
- font-family: "Courier New", Courier, monospace;
- font-size: inherit;
- color: navy;
+pre {
padding: 0;
margin: 0;
}
-
#author {
color: #527bbd;
font-weight: bold;
@@ -353,7 +349,7 @@
margin-bottom: 0.1em;
}
-div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
+div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
margin-top: 0;
margin-bottom: 0;
}
@@ -411,14 +407,18 @@
span.overline { text-decoration: overline; }
span.line-through { text-decoration: line-through; }
-div.unbreakable { page-break-inside: avoid; }
-
/*
* xhtml11 specific
*
* */
+tt {
+ font-family: monospace;
+ font-size: inherit;
+ color: navy;
+}
+
div.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
@@ -452,6 +452,12 @@
*
* */
+.monospaced {
+ font-family: monospace;
+ font-size: inherit;
+ color: navy;
+}
+
table.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
@@ -531,8 +537,6 @@
@media print {
body.manpage div#toc { display: none; }
}
-
-
</style>
<script type="text/javascript">
/*<![CDATA[*/
@@ -577,7 +581,7 @@
function tocEntries(el, toclevels) {
var result = new Array;
- var re = new RegExp('[hH]([1-'+(toclevels+1)+'])');
+ var re = new RegExp('[hH]([2-'+(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).
@@ -606,7 +610,7 @@
var i;
for (i = 0; i < toc.childNodes.length; i++) {
var entry = toc.childNodes[i];
- if (entry.nodeName.toLowerCase() == 'div'
+ if (entry.nodeName == 'div'
&& entry.getAttribute("class")
&& entry.getAttribute("class").match(/^toclevel/))
tocEntriesToRemove.push(entry);
@@ -652,7 +656,7 @@
var entriesToRemove = [];
for (i = 0; i < noteholder.childNodes.length; i++) {
var entry = noteholder.childNodes[i];
- if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote")
+ if (entry.nodeName == 'div' && entry.getAttribute("class") == "footnote")
entriesToRemove.push(entry);
}
for (i = 0; i < entriesToRemove.length; i++) {
@@ -731,22 +735,20 @@
</head>
<body class="article">
<div id="header">
+<h1>Concerning Git&#8217;s Packing Heuristics</h1>
</div>
<div id="content">
+<div id="preamble">
+<div class="sectionbody">
<div class="literalblock">
<div class="content">
-<pre><code>Concerning Git's Packing Heuristics
-===================================</code></pre>
+<pre><tt>Oh, here's a really stupid question:</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>Oh, here's a really stupid question:</code></pre>
-</div></div>
-<div class="literalblock">
-<div class="content">
-<pre><code> Where do I go
+<pre><tt> Where do I go
to learn the details
-of Git's packing heuristics?</code></pre>
+of Git's packing heuristics?</tt></pre>
</div></div>
<div class="paragraph"><p>Be careful what you ask!</p></div>
<div class="paragraph"><p>Followers of the Git, please open the Git IRC Log and turn to
@@ -757,11 +759,11 @@
<div class="paragraph"><p>Let&#8217;s listen in!</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; Oh, here's a really stupid question -- where do I go to
+<pre><tt>&lt;njs`&gt; Oh, here's a really stupid question -- where do I go to
learn the details of Git's packing heuristics? google avails
me not, reading the source didn't help a lot, and wading
through the whole mailing list seems less efficient than any
- of that.</code></pre>
+ of that.</tt></pre>
</div></div>
<div class="paragraph"><p>It is a bold start! A plea for help combined with a simultaneous
tri-part attack on some of the tried and true mainstays in the quest
@@ -770,65 +772,65 @@
Woe.</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;pasky&gt; yes, the packing-related delta stuff is somewhat
- mysterious even for me ;)</code></pre>
+<pre><tt>&lt;pasky&gt; yes, the packing-related delta stuff is somewhat
+ mysterious even for me ;)</tt></pre>
</div></div>
<div class="paragraph"><p>Ah! Modesty after all.</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; njs, I don't think the docs exist. That's something where
+<pre><tt>&lt;linus&gt; njs, I don't think the docs exist. That's something where
I don't think anybody else than me even really got involved.
Most of the rest of Git others have been busy with (especially
- Junio), but packing nobody touched after I did it.</code></pre>
+ Junio), but packing nobody touched after I did it.</tt></pre>
</div></div>
<div class="paragraph"><p>It&#8217;s cryptic, yet vague. Linus in style for sure. Wise men
interpret this as an apology. A few argue it is merely a
statement of fact.</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; I guess the next step is "read the source again", but I
- have to build up a certain level of gumption first :-)</code></pre>
+<pre><tt>&lt;njs`&gt; I guess the next step is "read the source again", but I
+ have to build up a certain level of gumption first :-)</tt></pre>
</div></div>
<div class="paragraph"><p>Indeed! On both points.</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; The packing heuristic is actually really really simple.</code></pre>
+<pre><tt>&lt;linus&gt; The packing heuristic is actually really really simple.</tt></pre>
</div></div>
<div class="paragraph"><p>Bait&#8230;</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; But strange.</code></pre>
+<pre><tt>&lt;linus&gt; But strange.</tt></pre>
</div></div>
<div class="paragraph"><p>And switch. That ought to do it!</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; Remember: Git really doesn't follow files. So what it does is
+<pre><tt>&lt;linus&gt; Remember: Git really doesn't follow files. So what it does is
- generate a list of all objects
- sort the list according to magic heuristics
- walk the list, using a sliding window, seeing if an object
can be diffed against another object in the window
- - write out the list in recency order</code></pre>
+ - write out the list in recency order</tt></pre>
</div></div>
<div class="paragraph"><p>The traditional understatement:</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; I suspect that what I'm missing is the precise definition of
- the word "magic"</code></pre>
+<pre><tt>&lt;njs`&gt; I suspect that what I'm missing is the precise definition of
+ the word "magic"</tt></pre>
</div></div>
<div class="paragraph"><p>The traditional insight:</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;pasky&gt; yes</code></pre>
+<pre><tt>&lt;pasky&gt; yes</tt></pre>
</div></div>
<div class="paragraph"><p>And Babel-like confusion flowed.</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; oh, hmm, and I'm not sure what this sliding window means either</code></pre>
+<pre><tt>&lt;njs`&gt; oh, hmm, and I'm not sure what this sliding window means either</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;pasky&gt; iirc, it appeared to me to be just the sha1 of the object
- when reading the code casually ...</code></pre>
+<pre><tt>&lt;pasky&gt; iirc, it appeared to me to be just the sha1 of the object
+ when reading the code casually ...</tt></pre>
</div></div>
<div class="olist lowerroman"><ol class="lowerroman">
<li>
@@ -837,83 +839,83 @@
</p>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; .....and recency order. okay, I think it's clear I didn't
- even realize how much I wasn't realizing :-)</code></pre>
+<pre><tt>&lt;njs`&gt; .....and recency order. okay, I think it's clear I didn't
+ even realize how much I wasn't realizing :-)</tt></pre>
</div></div>
</li>
</ol></div>
<div class="paragraph"><p>Ah, grasshopper! And thus the enlightenment begins anew.</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; The "magic" is actually in theory totally arbitrary.
+<pre><tt>&lt;linus&gt; The "magic" is actually in theory totally arbitrary.
ANY order will give you a working pack, but no, it's not
- ordered by SHA-1.</code></pre>
+ ordered by SHA-1.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>Before talking about the ordering for the sliding delta
+<pre><tt>Before talking about the ordering for the sliding delta
window, let's talk about the recency order. That's more
-important in one way.</code></pre>
+important in one way.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; Right, but if all you want is a working way to pack things
+<pre><tt>&lt;njs`&gt; Right, but if all you want is a working way to pack things
together, you could just use cat and save yourself some
- trouble...</code></pre>
+ trouble...</tt></pre>
</div></div>
<div class="paragraph"><p>Waaait for it&#8230;.</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; The recency ordering (which is basically: put objects
+<pre><tt>&lt;linus&gt; The recency ordering (which is basically: put objects
_physically_ into the pack in the order that they are
- "reachable" from the head) is important.</code></pre>
+ "reachable" from the head) is important.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; okay</code></pre>
+<pre><tt>&lt;njs`&gt; okay</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; It's important because that's the thing that gives packs
+<pre><tt>&lt;linus&gt; It's important because that's the thing that gives packs
good locality. It keeps the objects close to the head (whether
they are old or new, but they are _reachable_ from the head)
at the head of the pack. So packs actually have absolutely
- _wonderful_ IO patterns.</code></pre>
+ _wonderful_ IO patterns.</tt></pre>
</div></div>
<div class="paragraph"><p>Read that again, because it is important.</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; But recency ordering is totally useless for deciding how
+<pre><tt>&lt;linus&gt; But recency ordering is totally useless for deciding how
to actually generate the deltas, so the delta ordering is
- something else.</code></pre>
+ something else.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>The delta ordering is (wait for it):
+<pre><tt>The delta ordering is (wait for it):
- first sort by the "basename" of the object, as defined by
the name the object was _first_ reached through when
generating the object list
- within the same basename, sort by size of the object
-- but always sort different types separately (commits first).</code></pre>
+- but always sort different types separately (commits first).</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>That's not exactly it, but it's very close.</code></pre>
+<pre><tt>That's not exactly it, but it's very close.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; The "_first_ reached" thing is not too important, just you
+<pre><tt>&lt;njs`&gt; The "_first_ reached" thing is not too important, just you
need some way to break ties since the same objects may be
- reachable many ways, yes?</code></pre>
+ reachable many ways, yes?</tt></pre>
</div></div>
<div class="paragraph"><p>And as if to clarify:</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; The point is that it's all really just any random
+<pre><tt>&lt;linus&gt; The point is that it's all really just any random
heuristic, and the ordering is totally unimportant for
correctness, but it helps a lot if the heuristic gives
"clumping" for things that are likely to delta well against
- each other.</code></pre>
+ each other.</tt></pre>
</div></div>
<div class="paragraph"><p>It is an important point, so secretly, I did my own research and have
included my results below. To be fair, it has changed some over time.
@@ -921,7 +923,7 @@
from The Git IRC Logs on my father&#8217;s birthday, March 1:</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;gitster&gt; The quote from the above linus should be rewritten a
+<pre><tt>&lt;gitster&gt; The quote from the above linus should be rewritten a
bit (wait for it):
- first sort by type. Different objects never delta with
each other.
@@ -931,81 +933,81 @@
- then if we are doing "thin" pack, the objects we are _not_
going to pack but we know about are sorted earlier than
other objects.
- - and finally sort by size, larger to smaller.</code></pre>
+ - and finally sort by size, larger to smaller.</tt></pre>
</div></div>
<div class="paragraph"><p>In one swell-foop, clarification and obscurification! Nonetheless,
authoritative. Cryptic, yet concise. It even solicits notions of
quotes from The Source Code. Clearly, more study is needed.</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;gitster&gt; That's the sort order. What this means is:
+<pre><tt>&lt;gitster&gt; That's the sort order. What this means is:
- we do not delta different object types.
- we prefer to delta the objects with the same full path, but
allow files with the same name from different directories.
- we always prefer to delta against objects we are not going
to send, if there are some.
- we prefer to delta against larger objects, so that we have
- lots of removals.</code></pre>
+ lots of removals.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>The penultimate rule is for "thin" packs. It is used when
-the other side is known to have such objects.</code></pre>
+<pre><tt>The penultimate rule is for "thin" packs. It is used when
+the other side is known to have such objects.</tt></pre>
</div></div>
<div class="paragraph"><p>There it is again. "Thin" packs. I&#8217;m thinking to myself, "What
is a <em>thin</em> pack?" So I ask:</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;jdl&gt; What is a "thin" pack?</code></pre>
+<pre><tt>&lt;jdl&gt; What is a "thin" pack?</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;gitster&gt; Use of --objects-edge to rev-list as the upstream of
- pack-objects. The pack transfer protocol negotiates that.</code></pre>
+<pre><tt>&lt;gitster&gt; Use of --objects-edge to rev-list as the upstream of
+ pack-objects. The pack transfer protocol negotiates that.</tt></pre>
</div></div>
<div class="paragraph"><p>Woo hoo! Cleared that <em>right</em> up!</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;gitster&gt; There are two directions - push and fetch.</code></pre>
+<pre><tt>&lt;gitster&gt; There are two directions - push and fetch.</tt></pre>
</div></div>
<div class="paragraph"><p>There! Did you see it? It is not <em>"push" and "pull"</em>! How often the
confusion has started here. So casually mentioned, too!</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;gitster&gt; For push, git-send-pack invokes git-receive-pack on the
+<pre><tt>&lt;gitster&gt; For push, git-send-pack invokes git-receive-pack on the
other end. The receive-pack says "I have up to these commits".
send-pack looks at them, and computes what are missing from
- the other end. So "thin" could be the default there.</code></pre>
+ the other end. So "thin" could be the default there.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>In the other direction, fetch, git-fetch-pack and
+<pre><tt>In the other direction, fetch, git-fetch-pack and
git-clone-pack invokes git-upload-pack on the other end
-(via ssh or by talking to the daemon).</code></pre>
+(via ssh or by talking to the daemon).</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>There are two cases: fetch-pack with -k and clone-pack is one,
+<pre><tt>There are two cases: fetch-pack with -k and clone-pack is one,
fetch-pack without -k is the other. clone-pack and fetch-pack
with -k will keep the downloaded packfile without expanded, so
we do not use thin pack transfer. Otherwise, the generated
-pack will have delta without base object in the same pack.</code></pre>
+pack will have delta without base object in the same pack.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>But fetch-pack without -k will explode the received pack into
+<pre><tt>But fetch-pack without -k will explode the received pack into
individual objects, so we automatically ask upload-pack to
-give us a thin pack if upload-pack supports it.</code></pre>
+give us a thin pack if upload-pack supports it.</tt></pre>
</div></div>
<div class="paragraph"><p>OK then.</p></div>
<div class="paragraph"><p>Uh.</p></div>
<div class="paragraph"><p>Let&#8217;s return to the previous conversation still in progress.</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; and "basename" means something like "the tail of end of
+<pre><tt>&lt;njs`&gt; and "basename" means something like "the tail of end of
path of file objects and dir objects, as per basename(3), and
we just declare all commit and tag objects to have the same
- basename" or something?</code></pre>
+ basename" or something?</tt></pre>
</div></div>
<div class="paragraph"><p>Luckily, that too is a point that gitster clarified for us!</p></div>
<div class="paragraph"><p>If I might add, the trick is to make files that <em>might</em> be similar be
@@ -1019,73 +1021,73 @@
content no matter what directory they live in.</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; I played around with different delta algorithms, and with
+<pre><tt>&lt;linus&gt; I played around with different delta algorithms, and with
making the "delta window" bigger, but having too big of a
sliding window makes it very expensive to generate the pack:
- you need to compare every object with a _ton_ of other objects.</code></pre>
+ you need to compare every object with a _ton_ of other objects.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>There are a number of other trivial heuristics too, which
+<pre><tt>There are a number of other trivial heuristics too, which
basically boil down to "don't bother even trying to delta this
pair" if we can tell before-hand that the delta isn't worth it
(due to size differences, where we can take a previous delta
result into account to decide that "ok, no point in trying
-that one, it will be worse").</code></pre>
+that one, it will be worse").</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>End result: packing is actually very size efficient. It's
+<pre><tt>End result: packing is actually very size efficient. It's
somewhat CPU-wasteful, but on the other hand, since you're
really only supposed to do it maybe once a month (and you can
-do it during the night), nobody really seems to care.</code></pre>
+do it during the night), nobody really seems to care.</tt></pre>
</div></div>
<div class="paragraph"><p>Nice Engineering Touch, there. Find when it doesn&#8217;t matter, and
proclaim it a non-issue. Good style too!</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; So, just to repeat to see if I'm following, we start by
+<pre><tt>&lt;njs`&gt; So, just to repeat to see if I'm following, we start by
getting a list of the objects we want to pack, we sort it by
this heuristic (basically lexicographically on the tuple
- (type, basename, size)).</code></pre>
+ (type, basename, size)).</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>Then we walk through this list, and calculate a delta of
+<pre><tt>Then we walk through this list, and calculate a delta of
each object against the last n (tunable parameter) objects,
-and pick the smallest of these deltas.</code></pre>
+and pick the smallest of these deltas.</tt></pre>
</div></div>
<div class="paragraph"><p>Vastly simplified, but the essence is there!</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; Correct.</code></pre>
+<pre><tt>&lt;linus&gt; Correct.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; And then once we have picked a delta or fulltext to
+<pre><tt>&lt;njs`&gt; And then once we have picked a delta or fulltext to
represent each object, we re-sort by recency, and write them
- out in that order.</code></pre>
+ out in that order.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; Yup. Some other small details:</code></pre>
+<pre><tt>&lt;linus&gt; Yup. Some other small details:</tt></pre>
</div></div>
<div class="paragraph"><p>And of course there is the "Other Shoe" Factor too.</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; - We limit the delta depth to another magic value (right
- now both the window and delta depth magic values are just "10")</code></pre>
+<pre><tt>&lt;linus&gt; - We limit the delta depth to another magic value (right
+ now both the window and delta depth magic values are just "10")</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; Hrm, my intuition is that you'd end up with really _bad_ IO
+<pre><tt>&lt;njs`&gt; Hrm, my intuition is that you'd end up with really _bad_ IO
patterns, because the things you want are near by, but to
actually reconstruct them you may have to jump all over in
- random ways.</code></pre>
+ random ways.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; - When we write out a delta, and we haven't yet written
+<pre><tt>&lt;linus&gt; - When we write out a delta, and we haven't yet written
out the object it is a delta against, we write out the base
object first. And no, when we reconstruct them, we actually
get nice IO patterns, because:
@@ -1093,58 +1095,58 @@
- we actively try to generate deltas from a larger object to a
smaller one
- this means that the top-of-tree very seldom has deltas
- (i.e. deltas in _practice_ are "backwards deltas")</code></pre>
+ (i.e. deltas in _practice_ are "backwards deltas")</tt></pre>
</div></div>
<div class="paragraph"><p>Again, we should reread that whole paragraph. Not just because
Linus has slipped Linus&#8217;s Law in there on us, but because it is
important. Let&#8217;s make sure we clarify some of the points here:</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; So the point is just that in practice, delta order and
- recency order match each other quite well.</code></pre>
+<pre><tt>&lt;njs`&gt; So the point is just that in practice, delta order and
+ recency order match each other quite well.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; Yes. There's another nice side to this (and yes, it was
+<pre><tt>&lt;linus&gt; Yes. There's another nice side to this (and yes, it was
designed that way ;):
- the reason we generate deltas against the larger object is
- actually a big space saver too!</code></pre>
+ actually a big space saver too!</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; Hmm, but your last comment (if "we haven't yet written out
+<pre><tt>&lt;njs`&gt; Hmm, but your last comment (if "we haven't yet written out
the object it is a delta against, we write out the base object
first"), seems like it would make these facts mostly
irrelevant because even if in practice you would not have to
wander around much, in fact you just brute-force say that in
- the cases where you might have to wander, don't do that :-)</code></pre>
+ the cases where you might have to wander, don't do that :-)</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; Yes and no. Notice the rule: we only write out the base
+<pre><tt>&lt;linus&gt; Yes and no. Notice the rule: we only write out the base
object first if the delta against it was more recent. That
means that you can actually have deltas that refer to a base
object that is _not_ close to the delta object, but that only
- happens when the delta is needed to generate an _old_ object.</code></pre>
+ happens when the delta is needed to generate an _old_ object.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; See?</code></pre>
+<pre><tt>&lt;linus&gt; See?</tt></pre>
</div></div>
<div class="paragraph"><p>Yeah, no. I missed that on the first two or three readings myself.</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; This keeps the front of the pack dense. The front of the
+<pre><tt>&lt;linus&gt; This keeps the front of the pack dense. The front of the
pack never contains data that isn't relevant to a "recent"
object. The size optimization comes from our use of xdelta
(but is true for many other delta algorithms): removing data
- is cheaper (in size) than adding data.</code></pre>
+ is cheaper (in size) than adding data.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>When you remove data, you only need to say "copy bytes n--m".
+<pre><tt>When you remove data, you only need to say "copy bytes n--m".
In contrast, in a delta that _adds_ data, you have to say "add
-these bytes: 'actual data goes here'"</code></pre>
+these bytes: 'actual data goes here'"</tt></pre>
</div></div>
<div class="ulist"><ul>
<li>
@@ -1153,7 +1155,7 @@
</p>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; Uhhuh. I hope I didn't blow njs` mind.</code></pre>
+<pre><tt>&lt;linus&gt; Uhhuh. I hope I didn't blow njs` mind.</tt></pre>
</div></div>
</li>
<li>
@@ -1162,7 +1164,7 @@
</p>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;pasky&gt; :)</code></pre>
+<pre><tt>&lt;pasky&gt; :)</tt></pre>
</div></div>
</li>
</ul></div>
@@ -1170,7 +1172,7 @@
<div class="paragraph"><p>And as if njs` was expected to be omniscient:</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; njs - did you miss anything?</code></pre>
+<pre><tt>&lt;linus&gt; njs - did you miss anything?</tt></pre>
</div></div>
<div class="paragraph"><p>OK, I&#8217;ll spell it out. That&#8217;s Geek Humor. If njs` was not actually
connected for a little bit there, how would he know if missed anything
@@ -1178,168 +1180,170 @@
humor! Well noted!</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; Stupid router. Or gremlins, or whatever.</code></pre>
+<pre><tt>&lt;njs`&gt; Stupid router. Or gremlins, or whatever.</tt></pre>
</div></div>
<div class="paragraph"><p>It&#8217;s a cheap shot at Cisco. Take 'em when you can.</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; Yes and no. Notice the rule: we only write out the base
- object first if the delta against it was more recent.</code></pre>
+<pre><tt>&lt;njs`&gt; Yes and no. Notice the rule: we only write out the base
+ object first if the delta against it was more recent.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>I'm getting lost in all these orders, let me re-read :-)
+<pre><tt>I'm getting lost in all these orders, let me re-read :-)
So the write-out order is from most recent to least recent?
(Conceivably it could be the opposite way too, I'm not sure if
we've said) though my connection back at home is logging, so I
-can just read what you said there :-)</code></pre>
+can just read what you said there :-)</tt></pre>
</div></div>
<div class="paragraph"><p>And for those of you paying attention, the Omniscient Trick has just
been detailed!</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; Yes, we always write out most recent first</code></pre>
+<pre><tt>&lt;linus&gt; Yes, we always write out most recent first</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; And, yeah, I got the part about deeper-in-history stuff
- having worse IO characteristics, one sort of doesn't care.</code></pre>
+<pre><tt>&lt;njs`&gt; And, yeah, I got the part about deeper-in-history stuff
+ having worse IO characteristics, one sort of doesn't care.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; With the caveat that if the "most recent" needs an older
+<pre><tt>&lt;linus&gt; With the caveat that if the "most recent" needs an older
object to delta against (hey, shrinking sometimes does
- happen), we write out the old object with the delta.</code></pre>
+ happen), we write out the old object with the delta.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; (if only it happened more...)</code></pre>
+<pre><tt>&lt;njs`&gt; (if only it happened more...)</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; Anyway, the pack-file could easily be denser still, but
+<pre><tt>&lt;linus&gt; Anyway, the pack-file could easily be denser still, but
because it's used both for streaming (the Git protocol) and
- for on-disk, it has a few pessimizations.</code></pre>
+ for on-disk, it has a few pessimizations.</tt></pre>
</div></div>
<div class="paragraph"><p>Actually, it is a made-up word. But it is a made-up word being
used as setup for a later optimization, which is a real word:</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; In particular, while the pack-file is then compressed,
+<pre><tt>&lt;linus&gt; In particular, while the pack-file is then compressed,
it's compressed just one object at a time, so the actual
compression factor is less than it could be in theory. But it
means that it's all nice random-access with a simple index to
- do "object name-&gt;location in packfile" translation.</code></pre>
+ do "object name-&gt;location in packfile" translation.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; I'm assuming the real win for delta-ing large-&gt;small is
- more homogeneous statistics for gzip to run over?</code></pre>
+<pre><tt>&lt;njs`&gt; I'm assuming the real win for delta-ing large-&gt;small is
+ more homogeneous statistics for gzip to run over?</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>(You have to put the bytes in one place or another, but
-putting them in a larger blob wins on compression)</code></pre>
+<pre><tt>(You have to put the bytes in one place or another, but
+putting them in a larger blob wins on compression)</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>Actually, what is the compression strategy -- each delta
+<pre><tt>Actually, what is the compression strategy -- each delta
individually gzipped, the whole file gzipped, somewhere in
-between, no compression at all, ....?</code></pre>
+between, no compression at all, ....?</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>Right.</code></pre>
+<pre><tt>Right.</tt></pre>
</div></div>
<div class="paragraph"><p>Reality IRC sets in. For example:</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;pasky&gt; I'll read the rest in the morning, I really have to go
+<pre><tt>&lt;pasky&gt; I'll read the rest in the morning, I really have to go
sleep or there's no hope whatsoever for me at the today's
- exam... g'nite all.</code></pre>
+ exam... g'nite all.</tt></pre>
</div></div>
<div class="paragraph"><p>Heh.</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; pasky: g'nite</code></pre>
+<pre><tt>&lt;linus&gt; pasky: g'nite</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; pasky: 'luck</code></pre>
+<pre><tt>&lt;njs`&gt; pasky: 'luck</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; Right: large-&gt;small matters exactly because of compression
+<pre><tt>&lt;linus&gt; Right: large-&gt;small matters exactly because of compression
behaviour. If it was non-compressed, it probably wouldn't make
- any difference.</code></pre>
+ any difference.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;njs`&gt; yeah</code></pre>
+<pre><tt>&lt;njs`&gt; yeah</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; Anyway: I'm not even trying to claim that the pack-files
+<pre><tt>&lt;linus&gt; Anyway: I'm not even trying to claim that the pack-files
are perfect, but they do tend to have a nice balance of
- density vs ease-of use.</code></pre>
+ density vs ease-of use.</tt></pre>
</div></div>
<div class="paragraph"><p>Gasp! OK, saved. That&#8217;s a fair Engineering trade off. Close call!
In fact, Linus reflects on some Basic Engineering Fundamentals,
design options, etc.</p></div>
<div class="literalblock">
<div class="content">
-<pre><code>&lt;linus&gt; More importantly, they allow Git to still _conceptually_
- never deal with deltas at all, and be a "whole object" store.</code></pre>
+<pre><tt>&lt;linus&gt; More importantly, they allow Git to still _conceptually_
+ never deal with deltas at all, and be a "whole object" store.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>Which has some problems (we discussed bad huge-file
+<pre><tt>Which has some problems (we discussed bad huge-file
behaviour on the Git lists the other day), but it does mean
that the basic Git concepts are really really simple and
-straightforward.</code></pre>
+straightforward.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>It's all been quite stable.</code></pre>
+<pre><tt>It's all been quite stable.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>Which I think is very much a result of having very simple
+<pre><tt>Which I think is very much a result of having very simple
basic ideas, so that there's never any confusion about what's
-going on.</code></pre>
+going on.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
-<pre><code>Bugs happen, but they are "simple" bugs. And bugs that
+<pre><tt>Bugs happen, but they are "simple" bugs. And bugs that
actually get some object store detail wrong are almost always
-so obvious that they never go anywhere.</code></pre>
+so obvious that they never go anywhere.</tt></pre>
</div></div>