Autogenerated HTML docs for v1.5.6.1-156-ge903b

1 files changed, 13 insertions, 13 deletions

diff --git a/git-fast-import.html b/git-fast-import.html
index aedbe51e2..3a52e701a 100644
--- a/git-fast-import.html
+++ b/git-fast-import.html
@@ -272,21 +272,21 @@ git-fast-import(1) Manual Page
 </div>

 <h2>SYNOPSIS</h2>

 <div class="sectionbody">

-<p>frontend | <em>git-fast-import</em> [options]</p>

+<p>frontend | <em>git fast-import</em> [options]</p>

 </div>

 <h2>DESCRIPTION</h2>

 <div class="sectionbody">

 <p>This program is usually not what the end user wants to run directly.

 Most end users want to use one of the existing frontend programs,

 which parses a specific type of foreign source and feeds the contents

-stored there to git-fast-import.</p>

+stored there to <tt>git-fast-import</tt>.</p>

 <p>fast-import reads a mixed command/data stream from standard input and

 writes one or more packfiles directly into the current repository.

 When EOF is received on standard input, fast import writes out

 updated branch and tag refs, fully updating the current repository

 with the newly imported data.</p>

 <p>The fast-import backend itself can import into an empty repository (one that

-has already been initialized by <a href="git-init.html">git-init(1)</a>) or incrementally

+has already been initialized by <tt>git-init</tt>) or incrementally

 update an existing populated repository.  Whether or not incremental

 imports are supported from a particular foreign source depends on

 the frontend program in use.</p>

@@ -383,7 +383,7 @@ the frontend program in use.</p>
         This information may be useful after importing projects

         whose total object set exceeds the 4 GiB packfile limit,

         as these commits can be used as edge points during calls

-        to <a href="git-pack-objects.html">git-pack-objects(1)</a>.

+        to <tt>git-pack-objects</tt>.

 </p>

 </dd>

 <dt>

@@ -436,7 +436,7 @@ an ideal situation, given that most conversion tools are throw-away
 <div class="sectionbody">

 <p>Like <tt>git-push</tt> or <tt>git-fetch</tt>, imports handled by fast-import are safe to

 run alongside parallel <tt>git repack -a -d</tt> or <tt>git gc</tt> invocations,

-or any other Git operation (including <tt>git prune</tt>, as loose objects

+or any other Git operation (including <tt>git-prune</tt>, as loose objects

 are never used by fast-import).</p>

 <p>fast-import does not lock the branch or tag refs it is actively importing.

 After the import, during its ref update phase, fast-import tests each

@@ -526,7 +526,7 @@ variation in formatting will cause fast-import to reject the value.</p>
 </p>

 <p>An example value is &#8220;Tue Feb 6 11:22:18 2007 -0500&#8221;.  The Git

 parser is accurate, but a little on the lenient side.  It is the

-same parser used by <a href="git-am.html">git-am(1)</a> when applying patches

+same parser used by <tt>git-am</tt> when applying patches

 received from email.</p>

 <p>Some malformed strings may be accepted as valid dates.  In some of

 these cases Git will still be able to obtain the correct date from

@@ -561,7 +561,7 @@ timezone.</p>
 <p>This particular format is supplied as its short to implement and

 may be useful to a process that wants to create a new commit

 right now, without needing to use a working directory or

-<a href="git-update-index.html">git-update-index(1)</a>.</p>

+<tt>git-update-index</tt>.</p>

 <p>If separate <tt>author</tt> and <tt>committer</tt> commands are used in a <tt>commit</tt>

 the timestamps may not match, as the system clock will be polled

 twice (once for each command).  The only way to ensure that both

@@ -984,7 +984,7 @@ recommended, as the frontend does not (easily) have access to the
 complete set of bytes which normally goes into such a signature.

 If signing is required, create lightweight tags from within fast-import with

 <tt>reset</tt>, then create the annotated versions of those tags offline

-with the standard <a href="git-tag.html">git-tag(1)</a> process.</p>

+with the standard <tt>git-tag</tt> process.</p>

 <h3><tt>reset</tt></h3>

 <p>Creates (or recreates) the named branch, optionally starting from

 a specific revision.  The reset command allows a frontend to issue

@@ -1125,7 +1125,7 @@ remove the leading part of the line, for example:</p>
 <div class="exampleblock-content">

 <div class="literalblock">

 <div class="content">

-<pre><tt>frontend | git-fast-import | sed 's/^progress //'</tt></pre>

+<pre><tt>frontend | git fast-import | sed 's/^progress //'</tt></pre>

 </div></div>

 </div></div>

 <p>Placing a <tt>progress</tt> command immediately after a <tt>checkpoint</tt> will

@@ -1174,7 +1174,7 @@ END_OF_INPUT</tt></pre>
 </div></div>

 <div class="literalblock">

 <div class="content">

-<pre><tt>$ git-fast-import &lt;in

+<pre><tt>$ git fast-import &lt;in

 fatal: Corrupt mode: M 777 inline bob

 fast-import: dumping crash report to .git/fast_import_crash_8434</tt></pre>

 </div></div>

@@ -1279,7 +1279,7 @@ with real branches imported from the source (the name <tt>TAG_FIXUP</tt>
 is not <tt>refs/heads/TAG_FIXUP</tt>).</p>

 <p>When committing fixups, consider using <tt>merge</tt> to connect the

 commit(s) which are supplying file revisions to the fixup branch.

-Doing so will allow tools such as <a href="git-blame.html">git-blame(1)</a> to track

+Doing so will allow tools such as <tt>git-blame</tt> to track

 through the real commit history and properly annotate the source

 files.</p>

 <p>After fast-import terminates the frontend will need to do <tt>rm .git/TAG_FIXUP</tt>

@@ -1301,7 +1301,7 @@ situations.</p>
 <h3>Repacking Historical Data</h3>

 <p>If you are repacking very old imported data (e.g. older than the

 last year), consider expending some extra CPU time and supplying

---window=50 (or higher) when you run <a href="git-repack.html">git-repack(1)</a>.

+--window=50 (or higher) when you run <tt>git-repack</tt>.

 This will take longer, but will also produce a smaller packfile.

 You only need to expend the effort once, and everyone using your

 project will benefit from the smaller repository.</p>

@@ -1416,7 +1416,7 @@ memory footprint (less than 2.7 MiB per active branch).</p>
 </div>

 <div id="footer">

 <div id="footer-text">

-Last updated 08-Jun-2008 01:33:38 UTC

+Last updated 02-Jul-2008 03:01:43 UTC

 </div>

 </div>

 </body>