Merge branch 'maint'

[git.git] / Documentation / git-fast-import.txt

diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index ae87f0922781453f8a06c72f332dcacd4af1e968..19082b04eb7ec77bcf974e0c76b8d20bb736c021 100644 (file)
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -15,7 +15,7 @@ DESCRIPTION
 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
 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'.
+stored there to 'git fast-import'.

 
 fast-import reads a mixed command/data stream from standard input and
 writes one or more packfiles directly into the current repository.
 
 fast-import reads a mixed command/data stream from standard input and
 writes one or more packfiles directly into the current repository.


@@ -24,7 +24,7 @@ updated branch and tag refs, fully updating the current repository
 with the newly imported data.
 
 The fast-import backend itself can import into an empty repository (one that
 with the newly imported data.
 
 The fast-import backend itself can import into an empty repository (one that

-has already been initialized by 'git-init') or incrementally
+has already been initialized by 'git init') 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.
 update an existing populated repository.  Whether or not incremental
 imports are supported from a particular foreign source depends on
 the frontend program in use.


@@ -44,11 +44,14 @@ OPTIONS
        not contain the old commit).
 
 --max-pack-size=<n>::
        not contain the old commit).
 
 --max-pack-size=<n>::

-       Maximum size of each output packfile, expressed in MiB.
-       The default is 4096 (4 GiB) as that is the maximum allowed
-       packfile size (due to file format limitations). Some
-       importers may wish to lower this, such as to ensure the
-       resulting packfiles fit on CDs.
+       Maximum size of each output packfile.
+       The default is unlimited.
+
+--big-file-threshold=<n>::
+       Maximum size of a blob that fast-import will attempt to
+       create a delta for, expressed in bytes.  The default is 512m
+       (512 MiB).  Some importers may wish to lower this on systems
+       with constrained memory.

 
 --depth=<n>::
        Maximum delta depth, for blob and tree deltification.
 
 --depth=<n>::
        Maximum delta depth, for blob and tree deltification.


@@ -96,7 +99,7 @@ OPTIONS
        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
        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 'git-pack-objects'.
+       to 'git pack-objects'.

 
 --quiet::
        Disable all non-fatal output, making fast-import silent when it
 
 --quiet::
        Disable all non-fatal output, making fast-import silent when it


@@ -138,9 +141,9 @@ an ideal situation, given that most conversion tools are throw-away
 
 Parallel Operation
 ------------------
 
 Parallel Operation
 ------------------

-Like 'git-push' or 'git-fetch', imports handled by fast-import are safe to
+Like 'git push' or 'git fetch', imports handled by fast-import are safe to

 run alongside parallel `git repack -a -d` or `git gc` invocations,
 run alongside parallel `git repack -a -d` or `git gc` invocations,

-or any other Git operation (including 'git-prune', as loose objects
+or any other Git operation (including 'git prune', as loose objects

 are never used by fast-import).
 
 fast-import does not lock the branch or tag refs it is actively importing.
 are never used by fast-import).
 
 fast-import does not lock the branch or tag refs it is actively importing.


@@ -152,7 +155,7 @@ fast-forward update, fast-import will skip updating that ref and instead
 prints a warning message.  fast-import will always attempt to update all
 branch refs, and does not stop on the first failure.
 
 prints a warning message.  fast-import will always attempt to update all
 branch refs, and does not stop on the first failure.
 

-Branch updates can be forced with \--force, but its recommended that
+Branch updates can be forced with \--force, but it's recommended that

 this only be used on an otherwise quiet repository.  Using \--force
 is not necessary for an initial import into an empty repository.
 
 this only be used on an otherwise quiet repository.  Using \--force
 is not necessary for an initial import into an empty repository.
 


@@ -234,7 +237,7 @@ variation in formatting will cause fast-import to reject the value.
 +
 An example value is ``Tue Feb 6 11:22:18 2007 -0500''.  The Git
 parser is accurate, but a little on the lenient side.  It is the
 +
 An example value is ``Tue Feb 6 11:22:18 2007 -0500''.  The Git
 parser is accurate, but a little on the lenient side.  It is the

-same parser used by 'git-am' when applying patches
+same parser used by 'git am' when applying patches

 received from email.
 +
 Some malformed strings may be accepted as valid dates.  In some of
 received from email.
 +
 Some malformed strings may be accepted as valid dates.  In some of


@@ -267,10 +270,10 @@ is always copied into the identity string at the time it is being
 created by fast-import.  There is no way to specify a different time or
 timezone.
 +
 created by fast-import.  There is no way to specify a different time or
 timezone.
 +

-This particular format is supplied as its short to implement and
+This particular format is supplied as it's 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
 may be useful to a process that wants to create a new commit
 right now, without needing to use a working directory or

-'git-update-index'.
+'git update-index'.

 +
 If separate `author` and `committer` commands are used in a `commit`
 the timestamps may not match, as the system clock will be polled
 +
 If separate `author` and `committer` commands are used in a `commit`
 the timestamps may not match, as the system clock will be polled


@@ -420,7 +423,7 @@ quoting or escaping syntax is supported within `<committish>`.
 Here `<committish>` is any of the following:
 
 * The name of an existing branch already in fast-import's internal branch
 Here `<committish>` is any of the following:
 
 * The name of an existing branch already in fast-import's internal branch

-  table.  If fast-import doesn't know the name, its treated as a SHA-1
+  table.  If fast-import doesn't know the name, it's treated as a SHA-1

   expression.
 
 * A mark reference, `:<idnum>`, where `<idnum>` is the mark number.
   expression.
 
 * A mark reference, `:<idnum>`, where `<idnum>` is the mark number.


@@ -713,7 +716,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
 `reset`, then create the annotated versions of those tags offline
 complete set of bytes which normally goes into such a signature.
 If signing is required, create lightweight tags from within fast-import with
 `reset`, then create the annotated versions of those tags offline

-with the standard 'git-tag' process.
+with the standard 'git tag' process.

 
 `reset`
 ~~~~~~~
 
 `reset`
 ~~~~~~~


@@ -759,7 +762,7 @@ assigned mark.
 
 The mark command is optional here as some frontends have chosen
 to generate the Git SHA-1 for the blob on their own, and feed that
 
 The mark command is optional here as some frontends have chosen
 to generate the Git SHA-1 for the blob on their own, and feed that

-directly to `commit`.  This is typically more work than its worth
+directly to `commit`.  This is typically more work than it's worth

 however, as marks are inexpensive to store and easy to use.
 
 `data`
 however, as marks are inexpensive to store and easy to use.
 
 `data`


@@ -1070,7 +1073,7 @@ is not `refs/heads/TAG_FIXUP`).
 
 When committing fixups, consider using `merge` to connect the
 commit(s) which are supplying file revisions to the fixup branch.
 
 When committing fixups, consider using `merge` to connect the
 commit(s) which are supplying file revisions to the fixup branch.

-Doing so will allow tools such as 'git-blame' to track
+Doing so will allow tools such as 'git blame' to track

 through the real commit history and properly annotate the source
 files.
 
 through the real commit history and properly annotate the source
 files.
 


@@ -1099,7 +1102,7 @@ Repacking Historical Data
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 If you are repacking very old imported data (e.g. older than the
 last year), consider expending some extra CPU time and supplying
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 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 'git-repack'.
+\--window=50 (or higher) when you run 'git repack'.

 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.
 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.