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.
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.
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.
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
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,
-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.
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.
+
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
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
-'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
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.
* A complete 40 byte or abbreviated commit SHA-1 in hex.
* Any valid Git SHA-1 expression that resolves to a commit. See
- ``SPECIFYING REVISIONS'' in linkgit:git-rev-parse[1] for details.
+ ``SPECIFYING REVISIONS'' in linkgit:gitrevisions[1] for details.
The special case of restarting an incremental import from the
current branch value should be written as:
'M' SP <mode> SP <dataref> SP <path> LF
....
+
-Here `<dataref>` can be either a mark reference (`:<idnum>`)
+Here usually `<dataref>` must be either a mark reference (`:<idnum>`)
set by a prior `blob` command, or a full 40-byte SHA-1 of an
-existing Git blob object.
+existing Git blob object. If `<mode>` is `040000`` then
+`<dataref>` must be the full 40-byte SHA-1 of an existing
+Git tree object or a mark reference set with `--import-marks`.
Inline data format::
The data content for the file has not been supplied yet.
* `160000`: A gitlink, SHA-1 of the object refers to a commit in
another repository. Git links can only be specified by SHA or through
a commit mark. They are used to implement submodules.
+* `040000`: A subdirectory. Subdirectories can only be specified by
+ SHA or through a tree mark set with `--import-marks`.
In both formats `<path>` is the complete path of the file to be added
(if not already existing) or modified (if already existing).
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`
~~~~~~~
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`
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.
~~~~~~~~~~~~~~~~~~~~~~~~~
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.