NAME
----
-git-fast-import - Backend for fast Git data importers.
+git-fast-import - Backend for fast Git data importers
SYNOPSIS
Dumps the internal marks table to <file> when complete.
Marks are written one per line as `:markid SHA-1`.
Frontends can use this file to validate imports after they
- have been completed.
+ have been completed, or to save the marks table across
+ incremental runs. As <file> is only opened and truncated
+ at checkpoint (or completion) the same path can also be
+ safely given to \--import-marks.
+
+--import-marks=<file>::
+ Before processing any input, load the marks specified in
+ <file>. The input file must exist, must be readable, and
+ must use the same format as produced by \--export-marks.
+ Multiple options may be supplied to import more than one
+ set of marks. If a mark is defined to different values,
+ the last file wins.
--export-pack-edges=<file>::
After creating a packfile, print a line of data to
`from`
^^^^^^
-Only valid for the first commit made on this branch by this
-fast-import process. The `from` command is used to specify the commit
-to initialize this branch from. This revision will be the first
-ancestor of the new commit.
-
-Omitting the `from` command in the first commit of a new branch will
-cause fast-import to create that commit with no ancestor. This tends to be
-desired only for the initial commit of a project. Omitting the
-`from` command on existing branches is required, as the current
-commit on that branch is automatically assumed to be the first
-ancestor of the new commit.
+The `from` command is used to specify the commit to initialize
+this branch from. This revision will be the first ancestor of the
+new commit.
+
+Omitting the `from` command in the first commit of a new branch
+will cause fast-import to create that commit with no ancestor. This
+tends to be desired only for the initial commit of a project.
+Omitting the `from` command on existing branches is usually desired,
+as the current commit on that branch is automatically assumed to
+be the first ancestor of the new commit.
As `LF` is not valid in a Git refname or SHA-1 expression, no
quoting or escaping syntax is supported within `<committish>`.
In both formats `<path>` is the complete path of the file to be added
(if not already existing) or modified (if already existing).
-A `<path>` string must use UNIX-style directory seperators (forward
+A `<path>` string must use UNIX-style directory separators (forward
slash `/`), may contain any byte other than `LF`, and must not
start with double quote (`"`).
The value of `<path>` must be in canoncial form. That is it must not:
* contain an empty directory component (e.g. `foo//bar` is invalid),
-* end with a directory seperator (e.g. `foo/` is invalid),
-* start with a directory seperator (e.g. `/foo` is invalid),
+* end with a directory separator (e.g. `foo/` is invalid),
+* start with a directory separator (e.g. `/foo` is invalid),
* contain the special component `.` or `..` (e.g. `foo/./bar` and
`foo/../bar` are invalid).
`filedelete`
^^^^^^^^^^^^
-Included in a `commit` command to remove a file from the branch.
-If the file removal makes its directory empty, the directory will
+Included in a `commit` command to remove a file or recursively
+delete an entire directory from the branch. If the file or directory
+removal makes its parent directory empty, the parent directory will
be automatically removed too. This cascades up the tree until the
first non-empty directory or the root is reached.
'D' SP <path> LF
....
-here `<path>` is the complete path of the file to be removed.
+here `<path>` is the complete path of the file or subdirectory to
+be removed from the branch.
See `filemodify` above for a detailed description of `<path>`.
`filedeleteall`
'from' SP <committish> LF
'tagger' SP <name> SP LT <email> GT SP <when> LF
data
- LF
....
where `<name>` is the name of the tag to create.