Documentation / git-fast-import.txton commit Merge branch 'jk/run-command-use-shell' (4fa0882)
   1git-fast-import(1)
   2==================
   3
   4NAME
   5----
   6git-fast-import - Backend for fast Git data importers
   7
   8
   9SYNOPSIS
  10--------
  11frontend | 'git fast-import' [options]
  12
  13DESCRIPTION
  14-----------
  15This program is usually not what the end user wants to run directly.
  16Most end users want to use one of the existing frontend programs,
  17which parses a specific type of foreign source and feeds the contents
  18stored there to 'git-fast-import'.
  19
  20fast-import reads a mixed command/data stream from standard input and
  21writes one or more packfiles directly into the current repository.
  22When EOF is received on standard input, fast import writes out
  23updated branch and tag refs, fully updating the current repository
  24with the newly imported data.
  25
  26The fast-import backend itself can import into an empty repository (one that
  27has already been initialized by 'git-init') or incrementally
  28update an existing populated repository.  Whether or not incremental
  29imports are supported from a particular foreign source depends on
  30the frontend program in use.
  31
  32
  33OPTIONS
  34-------
  35--date-format=<fmt>::
  36        Specify the type of dates the frontend will supply to
  37        fast-import within `author`, `committer` and `tagger` commands.
  38        See ``Date Formats'' below for details about which formats
  39        are supported, and their syntax.
  40
  41--force::
  42        Force updating modified existing branches, even if doing
  43        so would cause commits to be lost (as the new commit does
  44        not contain the old commit).
  45
  46--max-pack-size=<n>::
  47        Maximum size of each output packfile, expressed in MiB.
  48        The default is 4096 (4 GiB) as that is the maximum allowed
  49        packfile size (due to file format limitations). Some
  50        importers may wish to lower this, such as to ensure the
  51        resulting packfiles fit on CDs.
  52
  53--depth=<n>::
  54        Maximum delta depth, for blob and tree deltification.
  55        Default is 10.
  56
  57--active-branches=<n>::
  58        Maximum number of branches to maintain active at once.
  59        See ``Memory Utilization'' below for details.  Default is 5.
  60
  61--export-marks=<file>::
  62        Dumps the internal marks table to <file> when complete.
  63        Marks are written one per line as `:markid SHA-1`.
  64        Frontends can use this file to validate imports after they
  65        have been completed, or to save the marks table across
  66        incremental runs.  As <file> is only opened and truncated
  67        at checkpoint (or completion) the same path can also be
  68        safely given to \--import-marks.
  69
  70--import-marks=<file>::
  71        Before processing any input, load the marks specified in
  72        <file>.  The input file must exist, must be readable, and
  73        must use the same format as produced by \--export-marks.
  74        Multiple options may be supplied to import more than one
  75        set of marks.  If a mark is defined to different values,
  76        the last file wins.
  77
  78--relative-marks::
  79        After specifying --relative-marks= the paths specified
  80        with --import-marks= and --export-marks= are relative
  81        to an internal directory in the current repository.
  82        In git-fast-import this means that the paths are relative
  83        to the .git/info/fast-import directory. However, other
  84        importers may use a different location.
  85
  86--no-relative-marks::
  87        Negates a previous --relative-marks. Allows for combining
  88        relative and non-relative marks by interweaving
  89        --(no-)-relative-marks= with the --(import|export)-marks=
  90        options.
  91
  92--export-pack-edges=<file>::
  93        After creating a packfile, print a line of data to
  94        <file> listing the filename of the packfile and the last
  95        commit on each branch that was written to that packfile.
  96        This information may be useful after importing projects
  97        whose total object set exceeds the 4 GiB packfile limit,
  98        as these commits can be used as edge points during calls
  99        to 'git-pack-objects'.
 100
 101--quiet::
 102        Disable all non-fatal output, making fast-import silent when it
 103        is successful.  This option disables the output shown by
 104        \--stats.
 105
 106--stats::
 107        Display some basic statistics about the objects fast-import has
 108        created, the packfiles they were stored into, and the
 109        memory used by fast-import during this run.  Showing this output
 110        is currently the default, but can be disabled with \--quiet.
 111
 112
 113Performance
 114-----------
 115The design of fast-import allows it to import large projects in a minimum
 116amount of memory usage and processing time.  Assuming the frontend
 117is able to keep up with fast-import and feed it a constant stream of data,
 118import times for projects holding 10+ years of history and containing
 119100,000+ individual commits are generally completed in just 1-2
 120hours on quite modest (~$2,000 USD) hardware.
 121
 122Most bottlenecks appear to be in foreign source data access (the
 123source just cannot extract revisions fast enough) or disk IO (fast-import
 124writes as fast as the disk will take the data).  Imports will run
 125faster if the source data is stored on a different drive than the
 126destination Git repository (due to less IO contention).
 127
 128
 129Development Cost
 130----------------
 131A typical frontend for fast-import tends to weigh in at approximately 200
 132lines of Perl/Python/Ruby code.  Most developers have been able to
 133create working importers in just a couple of hours, even though it
 134is their first exposure to fast-import, and sometimes even to Git.  This is
 135an ideal situation, given that most conversion tools are throw-away
 136(use once, and never look back).
 137
 138
 139Parallel Operation
 140------------------
 141Like 'git-push' or 'git-fetch', imports handled by fast-import are safe to
 142run alongside parallel `git repack -a -d` or `git gc` invocations,
 143or any other Git operation (including 'git-prune', as loose objects
 144are never used by fast-import).
 145
 146fast-import does not lock the branch or tag refs it is actively importing.
 147After the import, during its ref update phase, fast-import tests each
 148existing branch ref to verify the update will be a fast-forward
 149update (the commit stored in the ref is contained in the new
 150history of the commit to be written).  If the update is not a
 151fast-forward update, fast-import will skip updating that ref and instead
 152prints a warning message.  fast-import will always attempt to update all
 153branch refs, and does not stop on the first failure.
 154
 155Branch updates can be forced with \--force, but its recommended that
 156this only be used on an otherwise quiet repository.  Using \--force
 157is not necessary for an initial import into an empty repository.
 158
 159
 160Technical Discussion
 161--------------------
 162fast-import tracks a set of branches in memory.  Any branch can be created
 163or modified at any point during the import process by sending a
 164`commit` command on the input stream.  This design allows a frontend
 165program to process an unlimited number of branches simultaneously,
 166generating commits in the order they are available from the source
 167data.  It also simplifies the frontend programs considerably.
 168
 169fast-import does not use or alter the current working directory, or any
 170file within it.  (It does however update the current Git repository,
 171as referenced by `GIT_DIR`.)  Therefore an import frontend may use
 172the working directory for its own purposes, such as extracting file
 173revisions from the foreign source.  This ignorance of the working
 174directory also allows fast-import to run very quickly, as it does not
 175need to perform any costly file update operations when switching
 176between branches.
 177
 178Input Format
 179------------
 180With the exception of raw file data (which Git does not interpret)
 181the fast-import input format is text (ASCII) based.  This text based
 182format simplifies development and debugging of frontend programs,
 183especially when a higher level language such as Perl, Python or
 184Ruby is being used.
 185
 186fast-import is very strict about its input.  Where we say SP below we mean
 187*exactly* one space.  Likewise LF means one (and only one) linefeed.
 188Supplying additional whitespace characters will cause unexpected
 189results, such as branch names or file names with leading or trailing
 190spaces in their name, or early termination of fast-import when it encounters
 191unexpected input.
 192
 193Stream Comments
 194~~~~~~~~~~~~~~~
 195To aid in debugging frontends fast-import ignores any line that
 196begins with `#` (ASCII pound/hash) up to and including the line
 197ending `LF`.  A comment line may contain any sequence of bytes
 198that does not contain an LF and therefore may be used to include
 199any detailed debugging information that might be specific to the
 200frontend and useful when inspecting a fast-import data stream.
 201
 202Date Formats
 203~~~~~~~~~~~~
 204The following date formats are supported.  A frontend should select
 205the format it will use for this import by passing the format name
 206in the \--date-format=<fmt> command line option.
 207
 208`raw`::
 209        This is the Git native format and is `<time> SP <offutc>`.
 210        It is also fast-import's default format, if \--date-format was
 211        not specified.
 212+
 213The time of the event is specified by `<time>` as the number of
 214seconds since the UNIX epoch (midnight, Jan 1, 1970, UTC) and is
 215written as an ASCII decimal integer.
 216+
 217The local offset is specified by `<offutc>` as a positive or negative
 218offset from UTC.  For example EST (which is 5 hours behind UTC)
 219would be expressed in `<tz>` by ``-0500'' while UTC is ``+0000''.
 220The local offset does not affect `<time>`; it is used only as an
 221advisement to help formatting routines display the timestamp.
 222+
 223If the local offset is not available in the source material, use
 224``+0000'', or the most common local offset.  For example many
 225organizations have a CVS repository which has only ever been accessed
 226by users who are located in the same location and timezone.  In this
 227case a reasonable offset from UTC could be assumed.
 228+
 229Unlike the `rfc2822` format, this format is very strict.  Any
 230variation in formatting will cause fast-import to reject the value.
 231
 232`rfc2822`::
 233        This is the standard email format as described by RFC 2822.
 234+
 235An example value is ``Tue Feb 6 11:22:18 2007 -0500''.  The Git
 236parser is accurate, but a little on the lenient side.  It is the
 237same parser used by 'git-am' when applying patches
 238received from email.
 239+
 240Some malformed strings may be accepted as valid dates.  In some of
 241these cases Git will still be able to obtain the correct date from
 242the malformed string.  There are also some types of malformed
 243strings which Git will parse wrong, and yet consider valid.
 244Seriously malformed strings will be rejected.
 245+
 246Unlike the `raw` format above, the timezone/UTC offset information
 247contained in an RFC 2822 date string is used to adjust the date
 248value to UTC prior to storage.  Therefore it is important that
 249this information be as accurate as possible.
 250+
 251If the source material uses RFC 2822 style dates,
 252the frontend should let fast-import handle the parsing and conversion
 253(rather than attempting to do it itself) as the Git parser has
 254been well tested in the wild.
 255+
 256Frontends should prefer the `raw` format if the source material
 257already uses UNIX-epoch format, can be coaxed to give dates in that
 258format, or its format is easily convertible to it, as there is no
 259ambiguity in parsing.
 260
 261`now`::
 262        Always use the current time and timezone.  The literal
 263        `now` must always be supplied for `<when>`.
 264+
 265This is a toy format.  The current time and timezone of this system
 266is always copied into the identity string at the time it is being
 267created by fast-import.  There is no way to specify a different time or
 268timezone.
 269+
 270This particular format is supplied as its short to implement and
 271may be useful to a process that wants to create a new commit
 272right now, without needing to use a working directory or
 273'git-update-index'.
 274+
 275If separate `author` and `committer` commands are used in a `commit`
 276the timestamps may not match, as the system clock will be polled
 277twice (once for each command).  The only way to ensure that both
 278author and committer identity information has the same timestamp
 279is to omit `author` (thus copying from `committer`) or to use a
 280date format other than `now`.
 281
 282Commands
 283~~~~~~~~
 284fast-import accepts several commands to update the current repository
 285and control the current import process.  More detailed discussion
 286(with examples) of each command follows later.
 287
 288`commit`::
 289        Creates a new branch or updates an existing branch by
 290        creating a new commit and updating the branch to point at
 291        the newly created commit.
 292
 293`tag`::
 294        Creates an annotated tag object from an existing commit or
 295        branch.  Lightweight tags are not supported by this command,
 296        as they are not recommended for recording meaningful points
 297        in time.
 298
 299`reset`::
 300        Reset an existing branch (or a new branch) to a specific
 301        revision.  This command must be used to change a branch to
 302        a specific revision without making a commit on it.
 303
 304`blob`::
 305        Convert raw file data into a blob, for future use in a
 306        `commit` command.  This command is optional and is not
 307        needed to perform an import.
 308
 309`checkpoint`::
 310        Forces fast-import to close the current packfile, generate its
 311        unique SHA-1 checksum and index, and start a new packfile.
 312        This command is optional and is not needed to perform
 313        an import.
 314
 315`progress`::
 316        Causes fast-import to echo the entire line to its own
 317        standard output.  This command is optional and is not needed
 318        to perform an import.
 319
 320`feature`::
 321        Require that fast-import supports the specified feature, or
 322        abort if it does not.
 323
 324`option`::
 325        Specify any of the options listed under OPTIONS that do not
 326        change stream semantic to suit the frontend's needs. This
 327        command is optional and is not needed to perform an import.
 328
 329`commit`
 330~~~~~~~~
 331Create or update a branch with a new commit, recording one logical
 332change to the project.
 333
 334....
 335        'commit' SP <ref> LF
 336        mark?
 337        ('author' (SP <name>)? SP LT <email> GT SP <when> LF)?
 338        'committer' (SP <name>)? SP LT <email> GT SP <when> LF
 339        data
 340        ('from' SP <committish> LF)?
 341        ('merge' SP <committish> LF)?
 342        (filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)*
 343        LF?
 344....
 345
 346where `<ref>` is the name of the branch to make the commit on.
 347Typically branch names are prefixed with `refs/heads/` in
 348Git, so importing the CVS branch symbol `RELENG-1_0` would use
 349`refs/heads/RELENG-1_0` for the value of `<ref>`.  The value of
 350`<ref>` must be a valid refname in Git.  As `LF` is not valid in
 351a Git refname, no quoting or escaping syntax is supported here.
 352
 353A `mark` command may optionally appear, requesting fast-import to save a
 354reference to the newly created commit for future use by the frontend
 355(see below for format).  It is very common for frontends to mark
 356every commit they create, thereby allowing future branch creation
 357from any imported commit.
 358
 359The `data` command following `committer` must supply the commit
 360message (see below for `data` command syntax).  To import an empty
 361commit message use a 0 length data.  Commit messages are free-form
 362and are not interpreted by Git.  Currently they must be encoded in
 363UTF-8, as fast-import does not permit other encodings to be specified.
 364
 365Zero or more `filemodify`, `filedelete`, `filecopy`, `filerename`,
 366`filedeleteall` and `notemodify` commands
 367may be included to update the contents of the branch prior to
 368creating the commit.  These commands may be supplied in any order.
 369However it is recommended that a `filedeleteall` command precede
 370all `filemodify`, `filecopy`, `filerename` and `notemodify` commands in
 371the same commit, as `filedeleteall` wipes the branch clean (see below).
 372
 373The `LF` after the command is optional (it used to be required).
 374
 375`author`
 376^^^^^^^^
 377An `author` command may optionally appear, if the author information
 378might differ from the committer information.  If `author` is omitted
 379then fast-import will automatically use the committer's information for
 380the author portion of the commit.  See below for a description of
 381the fields in `author`, as they are identical to `committer`.
 382
 383`committer`
 384^^^^^^^^^^^
 385The `committer` command indicates who made this commit, and when
 386they made it.
 387
 388Here `<name>` is the person's display name (for example
 389``Com M Itter'') and `<email>` is the person's email address
 390(``cm@example.com'').  `LT` and `GT` are the literal less-than (\x3c)
 391and greater-than (\x3e) symbols.  These are required to delimit
 392the email address from the other fields in the line.  Note that
 393`<name>` is free-form and may contain any sequence of bytes, except
 394`LT` and `LF`.  It is typically UTF-8 encoded.
 395
 396The time of the change is specified by `<when>` using the date format
 397that was selected by the \--date-format=<fmt> command line option.
 398See ``Date Formats'' above for the set of supported formats, and
 399their syntax.
 400
 401`from`
 402^^^^^^
 403The `from` command is used to specify the commit to initialize
 404this branch from.  This revision will be the first ancestor of the
 405new commit.
 406
 407Omitting the `from` command in the first commit of a new branch
 408will cause fast-import to create that commit with no ancestor. This
 409tends to be desired only for the initial commit of a project.
 410If the frontend creates all files from scratch when making a new
 411branch, a `merge` command may be used instead of `from` to start
 412the commit with an empty tree.
 413Omitting the `from` command on existing branches is usually desired,
 414as the current commit on that branch is automatically assumed to
 415be the first ancestor of the new commit.
 416
 417As `LF` is not valid in a Git refname or SHA-1 expression, no
 418quoting or escaping syntax is supported within `<committish>`.
 419
 420Here `<committish>` is any of the following:
 421
 422* The name of an existing branch already in fast-import's internal branch
 423  table.  If fast-import doesn't know the name, its treated as a SHA-1
 424  expression.
 425
 426* A mark reference, `:<idnum>`, where `<idnum>` is the mark number.
 427+
 428The reason fast-import uses `:` to denote a mark reference is this character
 429is not legal in a Git branch name.  The leading `:` makes it easy
 430to distinguish between the mark 42 (`:42`) and the branch 42 (`42`
 431or `refs/heads/42`), or an abbreviated SHA-1 which happened to
 432consist only of base-10 digits.
 433+
 434Marks must be declared (via `mark`) before they can be used.
 435
 436* A complete 40 byte or abbreviated commit SHA-1 in hex.
 437
 438* Any valid Git SHA-1 expression that resolves to a commit.  See
 439  ``SPECIFYING REVISIONS'' in linkgit:git-rev-parse[1] for details.
 440
 441The special case of restarting an incremental import from the
 442current branch value should be written as:
 443----
 444        from refs/heads/branch^0
 445----
 446The `{caret}0` suffix is necessary as fast-import does not permit a branch to
 447start from itself, and the branch is created in memory before the
 448`from` command is even read from the input.  Adding `{caret}0` will force
 449fast-import to resolve the commit through Git's revision parsing library,
 450rather than its internal branch table, thereby loading in the
 451existing value of the branch.
 452
 453`merge`
 454^^^^^^^
 455Includes one additional ancestor commit.  If the `from` command is
 456omitted when creating a new branch, the first `merge` commit will be
 457the first ancestor of the current commit, and the branch will start
 458out with no files.  An unlimited number of `merge` commands per
 459commit are permitted by fast-import, thereby establishing an n-way merge.
 460However Git's other tools never create commits with more than 15
 461additional ancestors (forming a 16-way merge).  For this reason
 462it is suggested that frontends do not use more than 15 `merge`
 463commands per commit; 16, if starting a new, empty branch.
 464
 465Here `<committish>` is any of the commit specification expressions
 466also accepted by `from` (see above).
 467
 468`filemodify`
 469^^^^^^^^^^^^
 470Included in a `commit` command to add a new file or change the
 471content of an existing file.  This command has two different means
 472of specifying the content of the file.
 473
 474External data format::
 475        The data content for the file was already supplied by a prior
 476        `blob` command.  The frontend just needs to connect it.
 477+
 478....
 479        'M' SP <mode> SP <dataref> SP <path> LF
 480....
 481+
 482Here `<dataref>` can be either a mark reference (`:<idnum>`)
 483set by a prior `blob` command, or a full 40-byte SHA-1 of an
 484existing Git blob object.
 485
 486Inline data format::
 487        The data content for the file has not been supplied yet.
 488        The frontend wants to supply it as part of this modify
 489        command.
 490+
 491....
 492        'M' SP <mode> SP 'inline' SP <path> LF
 493        data
 494....
 495+
 496See below for a detailed description of the `data` command.
 497
 498In both formats `<mode>` is the type of file entry, specified
 499in octal.  Git only supports the following modes:
 500
 501* `100644` or `644`: A normal (not-executable) file.  The majority
 502  of files in most projects use this mode.  If in doubt, this is
 503  what you want.
 504* `100755` or `755`: A normal, but executable, file.
 505* `120000`: A symlink, the content of the file will be the link target.
 506* `160000`: A gitlink, SHA-1 of the object refers to a commit in
 507  another repository. Git links can only be specified by SHA or through
 508  a commit mark. They are used to implement submodules.
 509
 510In both formats `<path>` is the complete path of the file to be added
 511(if not already existing) or modified (if already existing).
 512
 513A `<path>` string must use UNIX-style directory separators (forward
 514slash `/`), may contain any byte other than `LF`, and must not
 515start with double quote (`"`).
 516
 517If an `LF` or double quote must be encoded into `<path>` shell-style
 518quoting should be used, e.g. `"path/with\n and \" in it"`.
 519
 520The value of `<path>` must be in canonical form. That is it must not:
 521
 522* contain an empty directory component (e.g. `foo//bar` is invalid),
 523* end with a directory separator (e.g. `foo/` is invalid),
 524* start with a directory separator (e.g. `/foo` is invalid),
 525* contain the special component `.` or `..` (e.g. `foo/./bar` and
 526  `foo/../bar` are invalid).
 527
 528It is recommended that `<path>` always be encoded using UTF-8.
 529
 530`filedelete`
 531^^^^^^^^^^^^
 532Included in a `commit` command to remove a file or recursively
 533delete an entire directory from the branch.  If the file or directory
 534removal makes its parent directory empty, the parent directory will
 535be automatically removed too.  This cascades up the tree until the
 536first non-empty directory or the root is reached.
 537
 538....
 539        'D' SP <path> LF
 540....
 541
 542here `<path>` is the complete path of the file or subdirectory to
 543be removed from the branch.
 544See `filemodify` above for a detailed description of `<path>`.
 545
 546`filecopy`
 547^^^^^^^^^^^^
 548Recursively copies an existing file or subdirectory to a different
 549location within the branch.  The existing file or directory must
 550exist.  If the destination exists it will be completely replaced
 551by the content copied from the source.
 552
 553....
 554        'C' SP <path> SP <path> LF
 555....
 556
 557here the first `<path>` is the source location and the second
 558`<path>` is the destination.  See `filemodify` above for a detailed
 559description of what `<path>` may look like.  To use a source path
 560that contains SP the path must be quoted.
 561
 562A `filecopy` command takes effect immediately.  Once the source
 563location has been copied to the destination any future commands
 564applied to the source location will not impact the destination of
 565the copy.
 566
 567`filerename`
 568^^^^^^^^^^^^
 569Renames an existing file or subdirectory to a different location
 570within the branch.  The existing file or directory must exist. If
 571the destination exists it will be replaced by the source directory.
 572
 573....
 574        'R' SP <path> SP <path> LF
 575....
 576
 577here the first `<path>` is the source location and the second
 578`<path>` is the destination.  See `filemodify` above for a detailed
 579description of what `<path>` may look like.  To use a source path
 580that contains SP the path must be quoted.
 581
 582A `filerename` command takes effect immediately.  Once the source
 583location has been renamed to the destination any future commands
 584applied to the source location will create new files there and not
 585impact the destination of the rename.
 586
 587Note that a `filerename` is the same as a `filecopy` followed by a
 588`filedelete` of the source location.  There is a slight performance
 589advantage to using `filerename`, but the advantage is so small
 590that it is never worth trying to convert a delete/add pair in
 591source material into a rename for fast-import.  This `filerename`
 592command is provided just to simplify frontends that already have
 593rename information and don't want bother with decomposing it into a
 594`filecopy` followed by a `filedelete`.
 595
 596`filedeleteall`
 597^^^^^^^^^^^^^^^
 598Included in a `commit` command to remove all files (and also all
 599directories) from the branch.  This command resets the internal
 600branch structure to have no files in it, allowing the frontend
 601to subsequently add all interesting files from scratch.
 602
 603....
 604        'deleteall' LF
 605....
 606
 607This command is extremely useful if the frontend does not know
 608(or does not care to know) what files are currently on the branch,
 609and therefore cannot generate the proper `filedelete` commands to
 610update the content.
 611
 612Issuing a `filedeleteall` followed by the needed `filemodify`
 613commands to set the correct content will produce the same results
 614as sending only the needed `filemodify` and `filedelete` commands.
 615The `filedeleteall` approach may however require fast-import to use slightly
 616more memory per active branch (less than 1 MiB for even most large
 617projects); so frontends that can easily obtain only the affected
 618paths for a commit are encouraged to do so.
 619
 620`notemodify`
 621^^^^^^^^^^^^
 622Included in a `commit` command to add a new note (annotating a given
 623commit) or change the content of an existing note.  This command has
 624two different means of specifying the content of the note.
 625
 626External data format::
 627        The data content for the note was already supplied by a prior
 628        `blob` command.  The frontend just needs to connect it to the
 629        commit that is to be annotated.
 630+
 631....
 632        'N' SP <dataref> SP <committish> LF
 633....
 634+
 635Here `<dataref>` can be either a mark reference (`:<idnum>`)
 636set by a prior `blob` command, or a full 40-byte SHA-1 of an
 637existing Git blob object.
 638
 639Inline data format::
 640        The data content for the note has not been supplied yet.
 641        The frontend wants to supply it as part of this modify
 642        command.
 643+
 644....
 645        'N' SP 'inline' SP <committish> LF
 646        data
 647....
 648+
 649See below for a detailed description of the `data` command.
 650
 651In both formats `<committish>` is any of the commit specification
 652expressions also accepted by `from` (see above).
 653
 654`mark`
 655~~~~~~
 656Arranges for fast-import to save a reference to the current object, allowing
 657the frontend to recall this object at a future point in time, without
 658knowing its SHA-1.  Here the current object is the object creation
 659command the `mark` command appears within.  This can be `commit`,
 660`tag`, and `blob`, but `commit` is the most common usage.
 661
 662....
 663        'mark' SP ':' <idnum> LF
 664....
 665
 666where `<idnum>` is the number assigned by the frontend to this mark.
 667The value of `<idnum>` is expressed as an ASCII decimal integer.
 668The value 0 is reserved and cannot be used as
 669a mark.  Only values greater than or equal to 1 may be used as marks.
 670
 671New marks are created automatically.  Existing marks can be moved
 672to another object simply by reusing the same `<idnum>` in another
 673`mark` command.
 674
 675`tag`
 676~~~~~
 677Creates an annotated tag referring to a specific commit.  To create
 678lightweight (non-annotated) tags see the `reset` command below.
 679
 680....
 681        'tag' SP <name> LF
 682        'from' SP <committish> LF
 683        'tagger' (SP <name>)? SP LT <email> GT SP <when> LF
 684        data
 685....
 686
 687where `<name>` is the name of the tag to create.
 688
 689Tag names are automatically prefixed with `refs/tags/` when stored
 690in Git, so importing the CVS branch symbol `RELENG-1_0-FINAL` would
 691use just `RELENG-1_0-FINAL` for `<name>`, and fast-import will write the
 692corresponding ref as `refs/tags/RELENG-1_0-FINAL`.
 693
 694The value of `<name>` must be a valid refname in Git and therefore
 695may contain forward slashes.  As `LF` is not valid in a Git refname,
 696no quoting or escaping syntax is supported here.
 697
 698The `from` command is the same as in the `commit` command; see
 699above for details.
 700
 701The `tagger` command uses the same format as `committer` within
 702`commit`; again see above for details.
 703
 704The `data` command following `tagger` must supply the annotated tag
 705message (see below for `data` command syntax).  To import an empty
 706tag message use a 0 length data.  Tag messages are free-form and are
 707not interpreted by Git.  Currently they must be encoded in UTF-8,
 708as fast-import does not permit other encodings to be specified.
 709
 710Signing annotated tags during import from within fast-import is not
 711supported.  Trying to include your own PGP/GPG signature is not
 712recommended, as the frontend does not (easily) have access to the
 713complete set of bytes which normally goes into such a signature.
 714If signing is required, create lightweight tags from within fast-import with
 715`reset`, then create the annotated versions of those tags offline
 716with the standard 'git-tag' process.
 717
 718`reset`
 719~~~~~~~
 720Creates (or recreates) the named branch, optionally starting from
 721a specific revision.  The reset command allows a frontend to issue
 722a new `from` command for an existing branch, or to create a new
 723branch from an existing commit without creating a new commit.
 724
 725....
 726        'reset' SP <ref> LF
 727        ('from' SP <committish> LF)?
 728        LF?
 729....
 730
 731For a detailed description of `<ref>` and `<committish>` see above
 732under `commit` and `from`.
 733
 734The `LF` after the command is optional (it used to be required).
 735
 736The `reset` command can also be used to create lightweight
 737(non-annotated) tags.  For example:
 738
 739====
 740        reset refs/tags/938
 741        from :938
 742====
 743
 744would create the lightweight tag `refs/tags/938` referring to
 745whatever commit mark `:938` references.
 746
 747`blob`
 748~~~~~~
 749Requests writing one file revision to the packfile.  The revision
 750is not connected to any commit; this connection must be formed in
 751a subsequent `commit` command by referencing the blob through an
 752assigned mark.
 753
 754....
 755        'blob' LF
 756        mark?
 757        data
 758....
 759
 760The mark command is optional here as some frontends have chosen
 761to generate the Git SHA-1 for the blob on their own, and feed that
 762directly to `commit`.  This is typically more work than its worth
 763however, as marks are inexpensive to store and easy to use.
 764
 765`data`
 766~~~~~~
 767Supplies raw data (for use as blob/file content, commit messages, or
 768annotated tag messages) to fast-import.  Data can be supplied using an exact
 769byte count or delimited with a terminating line.  Real frontends
 770intended for production-quality conversions should always use the
 771exact byte count format, as it is more robust and performs better.
 772The delimited format is intended primarily for testing fast-import.
 773
 774Comment lines appearing within the `<raw>` part of `data` commands
 775are always taken to be part of the body of the data and are therefore
 776never ignored by fast-import.  This makes it safe to import any
 777file/message content whose lines might start with `#`.
 778
 779Exact byte count format::
 780        The frontend must specify the number of bytes of data.
 781+
 782....
 783        'data' SP <count> LF
 784        <raw> LF?
 785....
 786+
 787where `<count>` is the exact number of bytes appearing within
 788`<raw>`.  The value of `<count>` is expressed as an ASCII decimal
 789integer.  The `LF` on either side of `<raw>` is not
 790included in `<count>` and will not be included in the imported data.
 791+
 792The `LF` after `<raw>` is optional (it used to be required) but
 793recommended.  Always including it makes debugging a fast-import
 794stream easier as the next command always starts in column 0
 795of the next line, even if `<raw>` did not end with an `LF`.
 796
 797Delimited format::
 798        A delimiter string is used to mark the end of the data.
 799        fast-import will compute the length by searching for the delimiter.
 800        This format is primarily useful for testing and is not
 801        recommended for real data.
 802+
 803....
 804        'data' SP '<<' <delim> LF
 805        <raw> LF
 806        <delim> LF
 807        LF?
 808....
 809+
 810where `<delim>` is the chosen delimiter string.  The string `<delim>`
 811must not appear on a line by itself within `<raw>`, as otherwise
 812fast-import will think the data ends earlier than it really does.  The `LF`
 813immediately trailing `<raw>` is part of `<raw>`.  This is one of
 814the limitations of the delimited format, it is impossible to supply
 815a data chunk which does not have an LF as its last byte.
 816+
 817The `LF` after `<delim> LF` is optional (it used to be required).
 818
 819`checkpoint`
 820~~~~~~~~~~~~
 821Forces fast-import to close the current packfile, start a new one, and to
 822save out all current branch refs, tags and marks.
 823
 824....
 825        'checkpoint' LF
 826        LF?
 827....
 828
 829Note that fast-import automatically switches packfiles when the current
 830packfile reaches \--max-pack-size, or 4 GiB, whichever limit is
 831smaller.  During an automatic packfile switch fast-import does not update
 832the branch refs, tags or marks.
 833
 834As a `checkpoint` can require a significant amount of CPU time and
 835disk IO (to compute the overall pack SHA-1 checksum, generate the
 836corresponding index file, and update the refs) it can easily take
 837several minutes for a single `checkpoint` command to complete.
 838
 839Frontends may choose to issue checkpoints during extremely large
 840and long running imports, or when they need to allow another Git
 841process access to a branch.  However given that a 30 GiB Subversion
 842repository can be loaded into Git through fast-import in about 3 hours,
 843explicit checkpointing may not be necessary.
 844
 845The `LF` after the command is optional (it used to be required).
 846
 847`progress`
 848~~~~~~~~~~
 849Causes fast-import to print the entire `progress` line unmodified to
 850its standard output channel (file descriptor 1) when the command is
 851processed from the input stream.  The command otherwise has no impact
 852on the current import, or on any of fast-import's internal state.
 853
 854....
 855        'progress' SP <any> LF
 856        LF?
 857....
 858
 859The `<any>` part of the command may contain any sequence of bytes
 860that does not contain `LF`.  The `LF` after the command is optional.
 861Callers may wish to process the output through a tool such as sed to
 862remove the leading part of the line, for example:
 863
 864====
 865        frontend | git fast-import | sed 's/^progress //'
 866====
 867
 868Placing a `progress` command immediately after a `checkpoint` will
 869inform the reader when the `checkpoint` has been completed and it
 870can safely access the refs that fast-import updated.
 871
 872`feature`
 873~~~~~~~~~
 874Require that fast-import supports the specified feature, or abort if
 875it does not.
 876
 877....
 878        'feature' SP <feature> LF
 879....
 880
 881The <feature> part of the command may be any string matching
 882^[a-zA-Z][a-zA-Z-]*$ and should be understood by fast-import.
 883
 884Feature work identical as their option counterparts with the
 885exception of the import-marks feature, see below.
 886
 887The following features are currently supported:
 888
 889* date-format
 890* import-marks
 891* export-marks
 892* relative-marks
 893* no-relative-marks
 894* force
 895
 896The import-marks behaves differently from when it is specified as
 897commandline option in that only one "feature import-marks" is allowed
 898per stream. Also, any --import-marks= specified on the commandline
 899will override those from the stream (if any).
 900
 901`option`
 902~~~~~~~~
 903Processes the specified option so that git fast-import behaves in a
 904way that suits the frontend's needs.
 905Note that options specified by the frontend are overridden by any
 906options the user may specify to git fast-import itself.
 907
 908....
 909    'option' SP <option> LF
 910....
 911
 912The `<option>` part of the command may contain any of the options
 913listed in the OPTIONS section that do not change import semantics,
 914without the leading '--' and is treated in the same way.
 915
 916Option commands must be the first commands on the input (not counting
 917feature commands), to give an option command after any non-option
 918command is an error.
 919
 920The following commandline options change import semantics and may therefore
 921not be passed as option:
 922
 923* date-format
 924* import-marks
 925* export-marks
 926* force
 927
 928Crash Reports
 929-------------
 930If fast-import is supplied invalid input it will terminate with a
 931non-zero exit status and create a crash report in the top level of
 932the Git repository it was importing into.  Crash reports contain
 933a snapshot of the internal fast-import state as well as the most
 934recent commands that lead up to the crash.
 935
 936All recent commands (including stream comments, file changes and
 937progress commands) are shown in the command history within the crash
 938report, but raw file data and commit messages are excluded from the
 939crash report.  This exclusion saves space within the report file
 940and reduces the amount of buffering that fast-import must perform
 941during execution.
 942
 943After writing a crash report fast-import will close the current
 944packfile and export the marks table.  This allows the frontend
 945developer to inspect the repository state and resume the import from
 946the point where it crashed.  The modified branches and tags are not
 947updated during a crash, as the import did not complete successfully.
 948Branch and tag information can be found in the crash report and
 949must be applied manually if the update is needed.
 950
 951An example crash:
 952
 953====
 954        $ cat >in <<END_OF_INPUT
 955        # my very first test commit
 956        commit refs/heads/master
 957        committer Shawn O. Pearce <spearce> 19283 -0400
 958        # who is that guy anyway?
 959        data <<EOF
 960        this is my commit
 961        EOF
 962        M 644 inline .gitignore
 963        data <<EOF
 964        .gitignore
 965        EOF
 966        M 777 inline bob
 967        END_OF_INPUT
 968
 969        $ git fast-import <in
 970        fatal: Corrupt mode: M 777 inline bob
 971        fast-import: dumping crash report to .git/fast_import_crash_8434
 972
 973        $ cat .git/fast_import_crash_8434
 974        fast-import crash report:
 975            fast-import process: 8434
 976            parent process     : 1391
 977            at Sat Sep 1 00:58:12 2007
 978
 979        fatal: Corrupt mode: M 777 inline bob
 980
 981        Most Recent Commands Before Crash
 982        ---------------------------------
 983          # my very first test commit
 984          commit refs/heads/master
 985          committer Shawn O. Pearce <spearce> 19283 -0400
 986          # who is that guy anyway?
 987          data <<EOF
 988          M 644 inline .gitignore
 989          data <<EOF
 990        * M 777 inline bob
 991
 992        Active Branch LRU
 993        -----------------
 994            active_branches = 1 cur, 5 max
 995
 996          pos  clock name
 997          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 998           1)      0 refs/heads/master
 999
1000        Inactive Branches
1001        -----------------
1002        refs/heads/master:
1003          status      : active loaded dirty
1004          tip commit  : 0000000000000000000000000000000000000000
1005          old tree    : 0000000000000000000000000000000000000000
1006          cur tree    : 0000000000000000000000000000000000000000
1007          commit clock: 0
1008          last pack   :
1009
1010
1011        -------------------
1012        END OF CRASH REPORT
1013====
1014
1015Tips and Tricks
1016---------------
1017The following tips and tricks have been collected from various
1018users of fast-import, and are offered here as suggestions.
1019
1020Use One Mark Per Commit
1021~~~~~~~~~~~~~~~~~~~~~~~
1022When doing a repository conversion, use a unique mark per commit
1023(`mark :<n>`) and supply the \--export-marks option on the command
1024line.  fast-import will dump a file which lists every mark and the Git
1025object SHA-1 that corresponds to it.  If the frontend can tie
1026the marks back to the source repository, it is easy to verify the
1027accuracy and completeness of the import by comparing each Git
1028commit to the corresponding source revision.
1029
1030Coming from a system such as Perforce or Subversion this should be
1031quite simple, as the fast-import mark can also be the Perforce changeset
1032number or the Subversion revision number.
1033
1034Freely Skip Around Branches
1035~~~~~~~~~~~~~~~~~~~~~~~~~~~
1036Don't bother trying to optimize the frontend to stick to one branch
1037at a time during an import.  Although doing so might be slightly
1038faster for fast-import, it tends to increase the complexity of the frontend
1039code considerably.
1040
1041The branch LRU builtin to fast-import tends to behave very well, and the
1042cost of activating an inactive branch is so low that bouncing around
1043between branches has virtually no impact on import performance.
1044
1045Handling Renames
1046~~~~~~~~~~~~~~~~
1047When importing a renamed file or directory, simply delete the old
1048name(s) and modify the new name(s) during the corresponding commit.
1049Git performs rename detection after-the-fact, rather than explicitly
1050during a commit.
1051
1052Use Tag Fixup Branches
1053~~~~~~~~~~~~~~~~~~~~~~
1054Some other SCM systems let the user create a tag from multiple
1055files which are not from the same commit/changeset.  Or to create
1056tags which are a subset of the files available in the repository.
1057
1058Importing these tags as-is in Git is impossible without making at
1059least one commit which ``fixes up'' the files to match the content
1060of the tag.  Use fast-import's `reset` command to reset a dummy branch
1061outside of your normal branch space to the base commit for the tag,
1062then commit one or more file fixup commits, and finally tag the
1063dummy branch.
1064
1065For example since all normal branches are stored under `refs/heads/`
1066name the tag fixup branch `TAG_FIXUP`.  This way it is impossible for
1067the fixup branch used by the importer to have namespace conflicts
1068with real branches imported from the source (the name `TAG_FIXUP`
1069is not `refs/heads/TAG_FIXUP`).
1070
1071When committing fixups, consider using `merge` to connect the
1072commit(s) which are supplying file revisions to the fixup branch.
1073Doing so will allow tools such as 'git-blame' to track
1074through the real commit history and properly annotate the source
1075files.
1076
1077After fast-import terminates the frontend will need to do `rm .git/TAG_FIXUP`
1078to remove the dummy branch.
1079
1080Import Now, Repack Later
1081~~~~~~~~~~~~~~~~~~~~~~~~
1082As soon as fast-import completes the Git repository is completely valid
1083and ready for use.  Typically this takes only a very short time,
1084even for considerably large projects (100,000+ commits).
1085
1086However repacking the repository is necessary to improve data
1087locality and access performance.  It can also take hours on extremely
1088large projects (especially if -f and a large \--window parameter is
1089used).  Since repacking is safe to run alongside readers and writers,
1090run the repack in the background and let it finish when it finishes.
1091There is no reason to wait to explore your new Git project!
1092
1093If you choose to wait for the repack, don't try to run benchmarks
1094or performance tests until repacking is completed.  fast-import outputs
1095suboptimal packfiles that are simply never seen in real use
1096situations.
1097
1098Repacking Historical Data
1099~~~~~~~~~~~~~~~~~~~~~~~~~
1100If you are repacking very old imported data (e.g. older than the
1101last year), consider expending some extra CPU time and supplying
1102\--window=50 (or higher) when you run 'git-repack'.
1103This will take longer, but will also produce a smaller packfile.
1104You only need to expend the effort once, and everyone using your
1105project will benefit from the smaller repository.
1106
1107Include Some Progress Messages
1108~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1109Every once in a while have your frontend emit a `progress` message
1110to fast-import.  The contents of the messages are entirely free-form,
1111so one suggestion would be to output the current month and year
1112each time the current commit date moves into the next month.
1113Your users will feel better knowing how much of the data stream
1114has been processed.
1115
1116
1117Packfile Optimization
1118---------------------
1119When packing a blob fast-import always attempts to deltify against the last
1120blob written.  Unless specifically arranged for by the frontend,
1121this will probably not be a prior version of the same file, so the
1122generated delta will not be the smallest possible.  The resulting
1123packfile will be compressed, but will not be optimal.
1124
1125Frontends which have efficient access to all revisions of a
1126single file (for example reading an RCS/CVS ,v file) can choose
1127to supply all revisions of that file as a sequence of consecutive
1128`blob` commands.  This allows fast-import to deltify the different file
1129revisions against each other, saving space in the final packfile.
1130Marks can be used to later identify individual file revisions during
1131a sequence of `commit` commands.
1132
1133The packfile(s) created by fast-import do not encourage good disk access
1134patterns.  This is caused by fast-import writing the data in the order
1135it is received on standard input, while Git typically organizes
1136data within packfiles to make the most recent (current tip) data
1137appear before historical data.  Git also clusters commits together,
1138speeding up revision traversal through better cache locality.
1139
1140For this reason it is strongly recommended that users repack the
1141repository with `git repack -a -d` after fast-import completes, allowing
1142Git to reorganize the packfiles for faster data access.  If blob
1143deltas are suboptimal (see above) then also adding the `-f` option
1144to force recomputation of all deltas can significantly reduce the
1145final packfile size (30-50% smaller can be quite typical).
1146
1147
1148Memory Utilization
1149------------------
1150There are a number of factors which affect how much memory fast-import
1151requires to perform an import.  Like critical sections of core
1152Git, fast-import uses its own memory allocators to amortize any overheads
1153associated with malloc.  In practice fast-import tends to amortize any
1154malloc overheads to 0, due to its use of large block allocations.
1155
1156per object
1157~~~~~~~~~~
1158fast-import maintains an in-memory structure for every object written in
1159this execution.  On a 32 bit system the structure is 32 bytes,
1160on a 64 bit system the structure is 40 bytes (due to the larger
1161pointer sizes).  Objects in the table are not deallocated until
1162fast-import terminates.  Importing 2 million objects on a 32 bit system
1163will require approximately 64 MiB of memory.
1164
1165The object table is actually a hashtable keyed on the object name
1166(the unique SHA-1).  This storage configuration allows fast-import to reuse
1167an existing or already written object and avoid writing duplicates
1168to the output packfile.  Duplicate blobs are surprisingly common
1169in an import, typically due to branch merges in the source.
1170
1171per mark
1172~~~~~~~~
1173Marks are stored in a sparse array, using 1 pointer (4 bytes or 8
1174bytes, depending on pointer size) per mark.  Although the array
1175is sparse, frontends are still strongly encouraged to use marks
1176between 1 and n, where n is the total number of marks required for
1177this import.
1178
1179per branch
1180~~~~~~~~~~
1181Branches are classified as active and inactive.  The memory usage
1182of the two classes is significantly different.
1183
1184Inactive branches are stored in a structure which uses 96 or 120
1185bytes (32 bit or 64 bit systems, respectively), plus the length of
1186the branch name (typically under 200 bytes), per branch.  fast-import will
1187easily handle as many as 10,000 inactive branches in under 2 MiB
1188of memory.
1189
1190Active branches have the same overhead as inactive branches, but
1191also contain copies of every tree that has been recently modified on
1192that branch.  If subtree `include` has not been modified since the
1193branch became active, its contents will not be loaded into memory,
1194but if subtree `src` has been modified by a commit since the branch
1195became active, then its contents will be loaded in memory.
1196
1197As active branches store metadata about the files contained on that
1198branch, their in-memory storage size can grow to a considerable size
1199(see below).
1200
1201fast-import automatically moves active branches to inactive status based on
1202a simple least-recently-used algorithm.  The LRU chain is updated on
1203each `commit` command.  The maximum number of active branches can be
1204increased or decreased on the command line with \--active-branches=.
1205
1206per active tree
1207~~~~~~~~~~~~~~~
1208Trees (aka directories) use just 12 bytes of memory on top of the
1209memory required for their entries (see ``per active file'' below).
1210The cost of a tree is virtually 0, as its overhead amortizes out
1211over the individual file entries.
1212
1213per active file entry
1214~~~~~~~~~~~~~~~~~~~~~
1215Files (and pointers to subtrees) within active trees require 52 or 64
1216bytes (32/64 bit platforms) per entry.  To conserve space, file and
1217tree names are pooled in a common string table, allowing the filename
1218``Makefile'' to use just 16 bytes (after including the string header
1219overhead) no matter how many times it occurs within the project.
1220
1221The active branch LRU, when coupled with the filename string pool
1222and lazy loading of subtrees, allows fast-import to efficiently import
1223projects with 2,000+ branches and 45,114+ files in a very limited
1224memory footprint (less than 2.7 MiB per active branch).
1225
1226
1227Author
1228------
1229Written by Shawn O. Pearce <spearce@spearce.org>.
1230
1231Documentation
1232--------------
1233Documentation by Shawn O. Pearce <spearce@spearce.org>.
1234
1235GIT
1236---
1237Part of the linkgit:git[1] suite