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.
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.
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'.
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).
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`