Autogenerated HTML docs for v1.6.6.1-383-g5a9f

1 files changed, 11 insertions, 11 deletions

diff --git a/git-fast-import.html b/git-fast-import.html
index 4f0164c30..9d591c944 100644
--- a/git-fast-import.html
+++ b/git-fast-import.html
@@ -327,14 +327,14 @@ git-fast-import(1) Manual Page
 <div class="para"><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 <em>git-fast-import</em>.</p></div>

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

 <div class="para"><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></div>

 <div class="para"><p>The fast-import backend itself can import into an empty repository (one that

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

+has already been initialized by <em>git init</em>) 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></div>

@@ -455,7 +455,7 @@ the frontend program in use.</p></div>
         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 <em>git-pack-objects</em>.

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

 </p>

 </dd>

 <dt>

@@ -506,9 +506,9 @@ an ideal situation, given that most conversion tools are throw-away
 </div>

 <h2 id="_parallel_operation">Parallel Operation</h2>

 <div class="sectionbody">

-<div class="para"><p>Like <em>git-push</em> or <em>git-fetch</em>, imports handled by fast-import are safe to

+<div class="para"><p>Like <em>git push</em> or <em>git fetch</em>, 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 <em>git-prune</em>, as loose objects

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

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

 <div class="para"><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

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

 <div class="para"><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 <em>git-am</em> when applying patches

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

 received from email.</p></div>

 <div class="para"><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

@@ -633,7 +633,7 @@ timezone.</p></div>
 <div class="para"><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

-<em>git-update-index</em>.</p></div>

+<em>git update-index</em>.</p></div>

 <div class="para"><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

@@ -1122,7 +1122,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 <em>git-tag</em> process.</p></div>

+with the standard <em>git tag</em> process.</p></div>

 <h3 id="_tt_reset_tt"><tt>reset</tt></h3><div style="clear:left"></div>

 <div class="para"><p>Creates (or recreates) the named branch, optionally starting from

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

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

 <div class="para"><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 <em>git-blame</em> to track

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

 through the real commit history and properly annotate the source

 files.</p></div>

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

@@ -1526,7 +1526,7 @@ situations.</p></div>
 <h3 id="_repacking_historical_data">Repacking Historical Data</h3><div style="clear:left"></div>

 <div class="para"><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 <em>git-repack</em>.

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

 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></div>

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

 <div id="footer">

 <div id="footer-text">

-Last updated 2010-01-18 01:25:21 UTC

+Last updated 2010-01-21 17:44:27 UTC

 </div>

 </div>

 </body>