~~~~~~~~~~~~
The following date formats are supported. A frontend should select
the format it will use for this import by passing the format name
-in the \--date-format=<fmt> command line option.
+in the \--date-format=<fmt> command-line option.
`raw`::
This is the Git native format and is `<time> SP <offutc>`.
If the local offset is not available in the source material, use
``+0000'', or the most common local offset. For example many
organizations have a CVS repository which has only ever been accessed
-by users who are located in the same location and timezone. In this
+by users who are located in the same location and time zone. In this
case a reasonable offset from UTC could be assumed.
+
Unlike the `rfc2822` format, this format is very strict. Any
strings which Git will parse wrong, and yet consider valid.
Seriously malformed strings will be rejected.
+
-Unlike the `raw` format above, the timezone/UTC offset information
+Unlike the `raw` format above, the time zone/UTC offset information
contained in an RFC 2822 date string is used to adjust the date
value to UTC prior to storage. Therefore it is important that
this information be as accurate as possible.
ambiguity in parsing.
`now`::
- Always use the current time and timezone. The literal
+ Always use the current time and time zone. The literal
`now` must always be supplied for `<when>`.
+
-This is a toy format. The current time and timezone of this system
+This is a toy format. The current time and time zone of this system
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.
+time zone.
+
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
`done`::
Marks the end of the stream. This command is optional
unless the `done` feature was requested using the
- `--done` command line option or `feature done` command.
+ `--done` command-line option or `feature done` command.
`cat-blob`::
Causes fast-import to print a blob in 'cat-file --batch'
('author' (SP <name>)? SP LT <email> GT SP <when> LF)?
'committer' (SP <name>)? SP LT <email> GT SP <when> LF
data
- ('from' SP <committish> LF)?
- ('merge' SP <committish> LF)?
+ ('from' SP <commit-ish> LF)?
+ ('merge' SP <commit-ish> LF)?
(filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)*
LF?
....
of bytes, except `LT`, `GT` and `LF`. `<name>` is typically UTF-8 encoded.
The time of the change is specified by `<when>` using the date format
-that was selected by the \--date-format=<fmt> command line option.
+that was selected by the \--date-format=<fmt> command-line option.
See ``Date Formats'' above for the set of supported formats, and
their syntax.
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>`.
+quoting or escaping syntax is supported within `<commit-ish>`.
-Here `<committish>` is any of the following:
+Here `<commit-ish>` 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, it's treated as a SHA-1
* Any valid Git SHA-1 expression that resolves to a commit. See
``SPECIFYING REVISIONS'' in linkgit:gitrevisions[7] for details.
+* The special null SHA-1 (40 zeros) specifies that the branch is to be
+ removed.
+
The special case of restarting an incremental import from the
current branch value should be written as:
----
it is suggested that frontends do not use more than 15 `merge`
commands per commit; 16, if starting a new, empty branch.
-Here `<committish>` is any of the commit specification expressions
+Here `<commit-ish>` is any of the commit specification expressions
also accepted by `from` (see above).
`filemodify`
`notemodify`
^^^^^^^^^^^^
Included in a `commit` `<notes_ref>` command to add a new note
-annotating a `<committish>` or change this annotation contents.
-Internally it is similar to filemodify 100644 on `<committish>`
+annotating a `<commit-ish>` or change this annotation contents.
+Internally it is similar to filemodify 100644 on `<commit-ish>`
path (maybe split into subdirectories). It's not advised to
use any other commands to write to the `<notes_ref>` tree except
`filedeleteall` to delete all existing notes in this tree.
commit that is to be annotated.
+
....
- 'N' SP <dataref> SP <committish> LF
+ 'N' SP <dataref> SP <commit-ish> LF
....
+
Here `<dataref>` can be either a mark reference (`:<idnum>`)
command.
+
....
- 'N' SP 'inline' SP <committish> LF
+ 'N' SP 'inline' SP <commit-ish> LF
data
....
+
See below for a detailed description of the `data` command.
-In both formats `<committish>` is any of the commit specification
+In both formats `<commit-ish>` is any of the commit specification
expressions also accepted by `from` (see above).
`mark`
....
'tag' SP <name> LF
- 'from' SP <committish> LF
+ 'from' SP <commit-ish> LF
'tagger' (SP <name>)? SP LT <email> GT SP <when> LF
data
....
....
'reset' SP <ref> LF
- ('from' SP <committish> LF)?
+ ('from' SP <commit-ish> LF)?
LF?
....
-For a detailed description of `<ref>` and `<committish>` see above
+For a detailed description of `<ref>` and `<commit-ish>` see above
under `commit` and `from`.
The `LF` after the command is optional (it used to be required).
feature commands), to give an option command after any non-option
command is an error.
-The following commandline options change import semantics and may therefore
+The following command-line options change import semantics and may therefore
not be passed as option:
* date-format
If the `done` feature is not in use, treated as if EOF was read.
This can be used to tell fast-import to finish early.
-If the `--done` command line option or `feature done` command is
+If the `--done` command-line option or `feature done` command is
in use, the `done` command is mandatory and marks the end of the
stream.