フロントエンドのデバッグを支援するために、fast-import は、# (ASCII ポンド/ハッシュ) で始まり、行末の LF を含むまでの行をすべて無視します。コメント行には、LF を含まない任意のバイトシーケンスを含めることができ、したがって、フロントエンドに固有であり、fast-import データストリームを検査するときに役立つ可能性のある詳細なデバッグ情報を含めるために使用できます。

次の日付形式がサポートされています。フロントエンドは、--date-format=<fmt> コマンドラインオプションで形式名を渡すことにより、このインポートに使用する形式を選択する必要があります。

fast-import は、現在のリポジトリを更新し、現在のインポートプロセスを制御するために、いくつかのコマンドを受け入れます。各コマンドの詳細な説明 (例を含む) は後述します。

新しいコミットでブランチを作成または更新し、プロジェクトへの論理的な変更を 1 つ記録します。

ここで、<ref> はコミットを行うブランチの名前です。通常、Git ではブランチ名のプレフィックスに refs/heads/ が付くため、CVS ブランチシンボル RELENG-1_0 をインポートする場合、<ref> の値には refs/heads/RELENG-1_0 を使用します。<ref> の値は、Git の有効な refname である必要があります。Git の refname では LF が無効であるため、ここでは引用符やエスケープ構文はサポートされていません。

mark コマンドをオプションで記述し、フロントエンドが後で使用できるように、新しく作成されたコミットへの参照を fast-import に保存するよう要求できます (形式については後述)。フロントエンドが作成するすべてのコミットをマークし、インポートされた任意のコミットから将来ブランチを作成できるようにするのが一般的です。

committer に続く data コマンドは、コミットメッセージを提供する必要があります (data コマンド構文については後述)。空のコミットメッセージをインポートするには、長さ 0 のデータを使用します。コミットメッセージは自由形式であり、Git によって解釈されることはありません。現在、UTF-8 でエンコードされている必要があります。fast-import では他のエンコードを指定することは許可されていません。

0 個以上の filemodify、filedelete、filecopy、filerename、filedeleteall、notemodify コマンドを含めて、コミットを作成する前にブランチの内容を更新できます。これらのコマンドは任意の順序で指定できます。ただし、同じコミット内で filedeleteall コマンドの後にすべての filemodify、filecopy、filerename、notemodify コマンドを続けることをお勧めします。filedeleteall はブランチを完全に消去するためです (後述参照)。

コマンド後の LF はオプションです (以前は必須でした)。後方互換性のために、コミットが data コマンドで終わる場合 (つまり、from、merge、filemodify、filedelete、filecopy、filerename、filedeleteall、または notemodify コマンドがない場合)、コマンドの最後に 1 つではなく 2 つの LF コマンドが表示される場合があります。

高速インポートに現在のオブジェクトへの参照を保存させ、フロントエンドがそのSHA-1を知らなくても、将来のある時点でこのオブジェクトを呼び出すことができるようにします。ここで、現在のオブジェクトは、markコマンドが表示されるオブジェクト作成コマンドです。これは、commit、tag、およびblobにできますが、commitが最も一般的な使用法です。

ここで、<idnum>は、フロントエンドによってこのマークに割り当てられた番号です。<idnum>の値は、ASCII 10進整数として表されます。値0は予約されており、マークとして使用することはできません。1以上の値のみをマークとして使用できます。

新しいマークは自動的に作成されます。既存のマークは、別のmarkコマンドで同じ<idnum>を再利用するだけで、別のオブジェクトに移動できます。

元のソース管理システムでのオブジェクトの名前を提供します。高速インポートはこのディレクティブを単に無視しますが、高速インポートにフィードする前にストリームを操作および変更するフィルター処理プロセスでは、この情報を使用する場合があります。

ここで、<object-identifier>はLFを含まない任意の文字列です。

特定のコミットを参照する注釈付きタグを作成します。軽量（非注釈付き）タグを作成するには、以下のresetコマンドを参照してください。

ここで、<name>は作成するタグの名前です。

タグ名はGitに保存されるときに自動的にrefs/tags/がプレフィックスとして付けられるため、CVSブランチシンボルRELENG-1_0-FINALをインポートする場合は、<name>にRELENG-1_0-FINALのみを使用し、高速インポートは対応する参照をrefs/tags/RELENG-1_0-FINALとして書き込みます。

<name>の値はGitの有効な参照名である必要があり、したがってスラッシュを含めることができます。LFはGit参照名では有効ではないため、ここで引用符またはエスケープ構文はサポートされていません。

fromコマンドは、commitコマンドと同じです。詳細については上記を参照してください。

taggerコマンドは、commit内のcommitterと同じ形式を使用します。こちらも詳細については上記を参照してください。

taggerに続くdataコマンドは、注釈付きタグメッセージを提供する必要があります（dataコマンドの構文については以下を参照）。空のタグメッセージをインポートするには、長さ0のデータを使用します。タグメッセージは自由形式であり、Gitによって解釈されることはありません。現在、高速インポートでは他のエンコーディングを指定できないため、UTF-8でエンコードする必要があります。

高速インポート内からのインポート中の注釈付きタグへの署名はサポートされていません。独自のPGP/GPG署名を含めようとすることはお勧めできません。フロントエンドは、通常そのような署名に使用される完全なバイトセットに（簡単には）アクセスできないためです。署名が必要な場合は、高速インポート内からresetを使用して軽量タグを作成し、標準のgit tagプロセスを使用してそれらのタグの注釈付きバージョンをオフラインで作成します。

指定されたリビジョンから開始することもできる、名前付きブランチを作成（または再作成）します。resetコマンドを使用すると、フロントエンドが既存のブランチに対して新しいfromコマンドを発行したり、新しいコミットを作成せずに既存のコミットから新しいブランチを作成したりできます。

<ref>と<commit-ish>の詳細については、上記のcommitおよびfromを参照してください。

コマンドの後のLFはオプションです（以前は必須でした）。

resetコマンドは、軽量（非注釈付き）タグを作成するためにも使用できます。たとえば

は、コミットマーク:938が参照するコミットを参照する軽量タグrefs/tags/938を作成します。

1つのファイルリビジョンをパックファイルに書き込むことを要求します。リビジョンはどのコミットにも接続されていません。この接続は、後続のcommitコマンドで、割り当てられたマークを介してblobを参照することによって形成する必要があります。

一部のフロントエンドはblobのGit SHA-1を独自に生成し、それをcommitに直接フィードすることを選択したため、ここではmarkコマンドはオプションです。ただし、マークは保存するのに安価で使いやすいため、通常、それだけの価値はありません。

高速インポートにrawデータ（blob/ファイルコンテンツ、コミットメッセージ、または注釈付きタグメッセージとして使用）を提供します。データは、正確なバイト数を使用するか、終了行で区切ることによって提供できます。実稼働品質の変換を目的とした実際のフロントエンドは、より堅牢でパフォーマンスが向上するため、常に正確なバイト数形式を使用する必要があります。区切り形式は、主に高速インポートのテストを目的としています。

dataコマンドの<raw>部分に表示されるコメント行は、常にデータ本体の一部と見なされ、したがって高速インポートによって無視されることはありません。これにより、行が#で始まる可能性のあるファイル/メッセージコンテンツを安全にインポートできます。

新しいオブジェクトを最初に作成せずに、マークが指定されたオブジェクトを参照することを記録します。

<commit-ish>の詳細については、上記のfromを参照してください。

高速インポートに、現在のパックファイルを閉じ、新しいパックファイルを開始し、現在のすべてのブランチ参照、タグ、およびマークを保存するように強制します。

高速インポートは、現在のパックファイルが--max-pack-sizeに達した場合、または4GiBに達した場合、どちらか小さい方の制限に達すると、自動的にパックファイルを切り替えることに注意してください。自動パックファイル切り替え中、高速インポートはブランチ参照、タグ、またはマークを更新しません。

checkpointにはかなりのCPU時間とディスクIO（パック全体のSHA-1チェックサムの計算、対応するインデックスファイルの生成、および参照の更新）が必要になる可能性があるため、1つのcheckpointコマンドの完了に数分かかることがあります。

フロントエンドは、非常に大規模で長期間実行されるインポート中、または別のGitプロセスがブランチにアクセスできるようにする必要がある場合に、チェックポイントを発行することを選択できます。ただし、30GiBのSubversionリポジトリを高速インポートを介して約3時間でGitにロードできることを考えると、明示的なチェックポイントは必要ない場合があります。

コマンドの後のLFはオプションです（以前は必須でした）。

コマンドが入力ストリームから処理されるときに、高速インポートが変更されていないprogress行全体を標準出力チャネル（ファイル記述子1）に出力するようにします。それ以外の場合、コマンドは現在のインポートにも、高速インポートの内部状態にも影響しません。

コマンドの <any> 部分には、LF を含まない任意のバイト列を含めることができます。コマンド後の LF はオプションです。呼び出し元は、行の先頭部分を削除するために、sed などのツールで出力を処理することができます。例えば、以下のように使用します。

checkpoint の直後に progress コマンドを置くと、checkpoint が完了し、fast-import が更新した参照に安全にアクセスできるタイミングをリーダーに通知できます。

fast-import に、マークに対応する SHA-1 を stdout または --cat-blob-fd 引数で事前に指定されたファイルディスクリプタに出力させます。このコマンドは、現在のインポートには影響を与えません。その目的は、後のコミットでコミットメッセージ内で参照する可能性のある SHA-1 を取得することです。

この出力の安全な読み取り方法については、下記の「コマンドへの応答」を参照してください。

fast-import に、blob を --cat-blob-fd 引数で事前に指定されたファイルディスクリプタに出力させます。このコマンドは、現在のインポートには影響を与えません。主な目的は、fast-import のメモリ内に存在するが、ターゲットリポジトリからはアクセスできない可能性のある blob を取得することです。

<dataref> には、以前に設定されたマーク参照 (:<idnum>) または、既存の、または書き込み準備ができた Git blob の完全な 40 バイトの SHA-1 を指定できます。

出力は git cat-file --batch と同じ形式を使用します。

このコマンドは、filemodify ディレクティブを使用できる場所で使用でき、コミットの途中で使用できます。インラインディレクティブを使用する filemodify の場合、data ディレクティブの直前にも表示できます。

この出力の安全な読み取り方法については、下記の「コマンドへの応答」を参照してください。

--cat-blob-fd 引数で事前に指定されたファイルディスクリプタに、パスにあるオブジェクトに関する情報を出力します。これにより、アクティブなコミットから blob を出力 (cat-blob を使用) したり、前のコミットから blob またはツリーをコピーして現在のコミットで使用 (filemodify を使用) したりできます。

ls コマンドは、filemodify ディレクティブを使用できる場所で使用でき、コミットの途中で使用できます。

<path> の詳細については、上記の filemodify を参照してください。

出力は git ls-tree <tree> -- <path> と同じ形式を使用します。

<dataref> は、<path> にある blob、ツリー、またはコミットオブジェクトを表し、後続の *get-mark*、*cat-blob*、*filemodify*、または *ls* コマンドで使用できます。

そのパスにファイルまたはサブツリーが存在しない場合、*git fast-import* は代わりに以下を報告します。

この出力の安全な読み取り方法については、下記の「コマンドへの応答」を参照してください。

fast-import が指定された機能をサポートすることを要求し、サポートしていない場合は中止します。

コマンドの <feature> 部分には、次のいずれかを指定できます。

指定されたオプションを処理して、git fast-import がフロントエンドのニーズに合った方法で動作するようにします。フロントエンドで指定されたオプションは、ユーザーが git fast-import 自体に指定したオプションによってオーバーライドされることに注意してください。

コマンドの <option> 部分には、OPTIONS セクションにリストされているオプションのうち、インポートセマンティクスを変更しないものを先頭の -- なしで含めることができ、同じ方法で扱われます。

オプションコマンドは、入力の最初のコマンドである必要があります (feature コマンドは除く)。オプション以外のコマンドの後にオプションコマンドを指定するとエラーになります。

次のコマンドラインオプションはインポートセマンティクスを変更するため、オプションとして渡すことはできません。

done 機能が使用されていない場合は、EOF が読み取られたかのように扱われます。これは、fast-import に早期終了を指示するために使用できます。

--done コマンドラインオプションまたは feature done コマンドを使用している場合、done コマンドは必須であり、ストリームの終了をマークします。

リポジトリの変換を行う場合は、コミットごとに一意のマーク (mark :<n>) を使用し、コマンドラインで --export-marks オプションを指定します。fast-import は、すべてのマークと、それに対応する Git オブジェクト SHA-1 をリストするファイルをダンプします。フロントエンドがマークをソースリポジトリに結び付けることができれば、各 Git コミットを対応するソースリビジョンと比較することで、インポートの正確性と完全性を簡単に検証できます。

Perforce や Subversion などのシステムから移行する場合は、fast-import マークは Perforce のチェンジセット番号または Subversion のリビジョン番号にもなるため、これは非常に簡単です。

インポート中に、フロントエンドを一度に1つのブランチに固定するように最適化しようとしないでください。そうすることで fast-import が若干高速になるかもしれませんが、フロントエンドコードの複雑さが大幅に増す傾向があります。

fast-import に組み込まれているブランチ LRU は非常にうまく動作する傾向があり、非アクティブなブランチをアクティブ化するコストは非常に低いため、ブランチ間を移動してもインポートパフォーマンスに実質的に影響はありません。

名前が変更されたファイルまたはディレクトリをインポートする場合、対応するコミット中に古い名前を削除し、新しい名前を変更するだけで済みます。Git はコミット中に明示的に名前変更を行うのではなく、事後的に名前変更の検出を実行します。

他の SCM システムの中には、ユーザーが同じコミット/チェンジセットに含まれない複数のファイルからタグを作成できるものがあります。または、リポジトリで使用可能なファイルのサブセットであるタグを作成できるものもあります。

これらのタグを Git にそのままインポートすることは、タグの内容と一致するようにファイルを「修正」するコミットを少なくとも 1 つ作成しない限り不可能です。fast-import の reset コマンドを使用して、通常のブランチスペース外のダミーブランチをタグのベースコミットにリセットし、1 つ以上のファイル修正コミットを行い、最後にダミーブランチにタグを付けます。

たとえば、通常のブランチはすべて refs/heads/ の下に格納されているため、タグ修正ブランチには TAG_FIXUP という名前を付けます。これにより、インポーターが使用する修正ブランチが、ソースからインポートされた実際のブランチとの名前空間の競合を起こすことがなくなります（TAG_FIXUP という名前は refs/heads/TAG_FIXUP ではありません）。

修正をコミットする際は、ファイルリビジョンを修正ブランチに提供するコミットを接続するために merge を使用することを検討してください。そうすることで、*git blame* などのツールが実際のコミット履歴を追跡し、ソースファイルに適切に注釈を付けることができます。

fast-import が終了した後、フロントエンドはダミーブランチを削除するために rm .git/TAG_FIXUP を実行する必要があります。

fast-import が完了するとすぐに、Git リポジトリは完全に有効になり、使用できるようになります。通常、これは非常に大規模なプロジェクト（100,000 件以上のコミット）でもごく短時間しかかかりません。

ただし、データローカリティとアクセスパフォーマンスを向上させるには、リポジトリをリパックする必要があります。また、非常に大規模なプロジェクト（特に -f と大きな --window パラメーターを使用した場合）では、数時間かかる場合があります。リパックは読み取り/書き込みと並行して安全に実行できるため、バックグラウンドでリパックを実行し、完了するまで待ちます。新しい Git プロジェクトを探索するために待つ必要はありません。

リパックを待つ場合は、リパックが完了するまでベンチマークやパフォーマンステストを実行しようとしないでください。fast-import は、実際には決して見られない最適でないパックファイルを出力します。

非常に古いインポートデータ（例：過去 1 年よりも古いデータ）をリパックする場合は、余分な CPU 時間を費やし、*git repack* を実行するときに --window=50 (またはそれ以上) を指定することを検討してください。これにより時間がかかりますが、より小さなパックファイルも生成されます。努力は一度だけで済み、プロジェクトを使用するすべての人が、より小さなリポジトリの恩恵を受けることができます。

時々、フロントエンドで fast-import に progress メッセージを発行するようにします。メッセージの内容は完全に自由形式なので、現在のコミット日が次の月に移動するたびに、現在の月と年を出力することをお勧めします。ユーザーは、データストリームがどの程度処理されたかを知ることができ、安心できます。

fast-import は、この実行で書き込まれたすべてのオブジェクトに対してインメモリ構造を維持します。32 ビットシステムでは、構造は 32 バイトで、64 ビットシステムでは、構造は 40 バイトです（ポインタサイズが大きいため）。テーブル内のオブジェクトは、fast-import が終了するまで割り当て解除されません。32 ビットシステムで 200 万個のオブジェクトをインポートするには、約 64 MiB のメモリが必要になります。

オブジェクトテーブルは、実際にはオブジェクト名（一意の SHA-1）をキーとするハッシュテーブルです。このストレージ構成により、fast-import は既存またはすでに書き込まれたオブジェクトを再利用し、出力パックファイルへの重複書き込みを回避できます。重複したブロブはインポートで驚くほど一般的であり、通常はソースのブランチマージが原因です。

マークは、マークごとに 1 つのポインター（ポインターサイズに応じて 4 バイトまたは 8 バイト）を使用して、スパース配列に格納されます。配列はスパースですが、フロントエンドは、このインポートに必要なマークの総数 n の範囲で 1 から n の間のマークを使用することを強くお勧めします。

ブランチは、アクティブと非アクティブに分類されます。2 つのクラスのメモリ使用量は大きく異なります。

非アクティブなブランチは、ブランチごとに 96 または 120 バイト（それぞれ 32 ビットまたは 64 ビットシステム）と、ブランチ名の長さ（通常は 200 バイト未満）を使用する構造に格納されます。fast-import は、2 MiB 未満のメモリで最大 10,000 個の非アクティブなブランチを簡単に処理できます。

アクティブなブランチは、非アクティブなブランチと同じオーバーヘッドがありますが、そのブランチで最近変更されたすべてのツリーのコピーも含まれています。サブツリー include がブランチがアクティブになってから変更されていない場合、その内容はメモリにロードされませんが、サブツリー src がブランチがアクティブになってからコミットによって変更された場合、その内容はメモリにロードされます。

アクティブなブランチは、そのブランチに含まれるファイルに関するメタデータを格納するため、そのインメモリストレージサイズはかなりのサイズにまで拡大する可能性があります（下記参照）。

fast-import は、単純な最長未使用アルゴリズムに基づいて、アクティブなブランチを自動的に非アクティブなステータスに移動します。LRU チェーンは、各 commit コマンドで更新されます。アクティブなブランチの最大数は、コマンドラインで --active-branches= を使用して増減できます。

ツリー（別名ディレクトリ）は、そのエントリに必要なメモリ（下記の「アクティブなファイルごと」を参照）に加えて、わずか 12 バイトのメモリを使用します。ツリーのコストは事実上 0 です。これは、そのオーバーヘッドが個々のファイルエントリに分散されるためです。

アクティブなツリー内のファイル（およびサブツリーへのポインター）は、エントリごとに 52 または 64 バイト（32/64 ビットプラットフォーム）が必要です。スペースを節約するために、ファイル名とツリー名は共通の文字列テーブルにプールされるため、ファイル名「Makefile」は、プロジェクト内で何回発生しても、わずか 16 バイト（文字列ヘッダーのオーバーヘッドを含む）しか使用しません。

アクティブなブランチ LRU は、ファイル名文字列プールおよびサブツリーの遅延ロードと組み合わされると、fast-import は、非常に限られたメモリフットプリント（アクティブなブランチあたり 2.7 MiB 未満）で、2,000 以上のブランチと 45,114 以上のファイルを含むプロジェクトを効率的にインポートできます。