Git Fast Import Commands: Mark, Tag, Reset, and Blob

appears within. This can be `commit`, `tag`, and `blob`, but `commit` is the most common usage. .... 'mark' SP ':' <idnum> LF .... where `<idnum>` is the number assigned by the frontend to this mark. The value of `<idnum>` is expressed as an ASCII decimal integer. The value 0 is reserved and cannot be used as a mark. Only values greater than or equal to 1 may be used as marks. New marks are created automatically. Existing marks can be moved to another object simply by reusing the same `<idnum>` in another `mark` command. `original-oid` ~~~~~~~~~~~~~~ Provides the name of the object in the original source control system. fast-import will simply ignore this directive, but filter processes which operate on and modify the stream before feeding to fast-import may have uses for this information .... 'original-oid' SP <object-identifier> LF .... where `<object-identifier>` is any string not containing LF. `tag` ~~~~~ Creates an annotated tag referring to a specific commit. To create lightweight (non-annotated) tags see the `reset` command below. .... 'tag' SP <name> LF mark? 'from' SP <commit-ish> LF original-oid? 'tagger' (SP <name>)? SP LT <email> GT SP <when> LF data .... where `<name>` is the name of the tag to create. Tag names are automatically prefixed with `refs/tags/` when stored in Git, so importing the CVS branch symbol `RELENG-1_0-FINAL` would use just `RELENG-1_0-FINAL` for `<name>`, and fast-import will write the corresponding ref as `refs/tags/RELENG-1_0-FINAL`. The value of `<name>` must be a valid refname in Git and therefore may contain forward slashes. As `LF` is not valid in a Git refname, no quoting or escaping syntax is supported here. The `from` command is the same as in the `commit` command; see above for details. The `tagger` command uses the same format as `committer` within `commit`; again see above for details. The `data` command following `tagger` must supply the annotated tag message (see below for `data` command syntax). To import an empty tag message use a 0 length data. Tag messages are free-form and are not interpreted by Git. Currently they must be encoded in UTF-8, as fast-import does not permit other encodings to be specified. Signing annotated tags during import from within fast-import is not supported. Trying to include your own PGP/GPG signature is not 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 with the standard 'git tag' process. `reset` ~~~~~~~ Creates (or recreates) the named branch, optionally starting from a specific revision. The reset command allows a frontend to issue a new `from` command for an existing branch, or to create a new branch from an existing commit without creating a new commit. .... 'reset' SP <ref> LF ('from' SP <commit-ish> LF)? LF? .... 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). The `reset` command can also be used to create lightweight (non-annotated) tags. For example: ==== reset refs/tags/938 from :938 ==== would create the lightweight tag `refs/tags/938` referring to whatever commit mark `:938` references. `blob` ~~~~~~ Requests writing one file revision to the packfile. The revision is not connected to any commit; this connection must be formed in a subsequent `commit` command by referencing the blob through an assigned mark. .... 'blob' LF mark? original-oid? data .... 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 it's worth however, as marks are inexpensive to store and easy to use. `data` ~~~~~~ Supplies raw data (for use as blob/file

The git-fast-import command provides options for creating marks, annotated tags, resetting branches, and writing blob revisions, with specific syntax and rules for each command, allowing frontends to interact with the Git repository and create a stream of commands for fast-import to process, including creating lightweight tags, supplying raw data, and referencing objects using marks and commit-ish expressions.