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

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

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

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

ここで、<ref> はコミットを行うブランチの名前です。通常、Git のブランチ名は refs/heads/ で始まるため、CVS ブランチシンボル RELENG-1_0 をインポートする場合、<ref> の値として refs/heads/RELENG-1_0 を使用します。<ref> の値は Git の有効な参照名でなければなりません。LF は Git の参照名では無効なため、ここでは引用符またはエスケープ構文はサポートされていません。

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

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

コミットを作成する前に、ブランチの内容を更新するために、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 コマンドが現れる場合があります。

fast-import に現在のオブジェクトへの参照を保存するように手配し、フロントエンドがその SHA-1 を知ることなく、将来このオブジェクトを呼び出すことを可能にします。ここで、現在のオブジェクトは、mark コマンドが現れるオブジェクト作成コマンドです。これは commit、tag、blob のいずれかですが、commit が最も一般的な使用法です。

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

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

元のソース管理システム内のオブジェクトの名前を提供します。fast-import はこのディレクティブを単純に無視しますが、fast-import に供給する前にストリームを操作および変更するフィルタプロセスは、この情報を使用する可能性があります。

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

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

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

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

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

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

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

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

fast-import 内からのインポート中に注釈付きタグに署名することはサポートされていません。独自の PGP/GPG 署名を含めようとすることは推奨されません。フロントエンドは通常、そのような署名に必要なバイトの完全なセットに (容易に) アクセスできないためです。署名が必要な場合、fast-import 内から reset で軽量タグを作成し、その後、標準の *git tag* プロセスでオフラインでそれらのタグの注釈付きバージョンを作成してください。

指定されたブランチを作成 (または再作成) し、オプションで特定の改訂から開始します。reset コマンドにより、フロントエンドは既存のブランチに対して新しい from コマンドを発行したり、新しいコミットを作成せずに既存のコミットから新しいブランチを作成したりできます。

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

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

reset コマンドは、軽量 (非注釈付き) タグを作成するためにも使用できます。例:

これにより、マーク :938 が参照するコミットを参照する軽量タグ refs/tags/938 が作成されます。

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

ここではマークコマンドはオプションです。一部のフロントエンドは、BLOB の Git SHA-1 を独自に生成し、それを直接 commit に供給することを選択したためです。しかし、マークは保存が安価で使いやすいため、通常はそれだけの労力に見合いません。

生データ (BLOB/ファイルコンテンツ、コミットメッセージ、または注釈付きタグメッセージとして使用) を fast-import に供給します。データは正確なバイト数で指定するか、終了行で区切って供給できます。本番品質の変換を目的とした実際のフロントエンドは、より堅牢でパフォーマンスが高いため、常に正確なバイト数形式を使用する必要があります。区切り形式は、主に fast-import のテストを目的としています。

data コマンドの <raw> 部分に現れるコメント行は、常にデータ本文の一部と見なされ、fast-import によって決して無視されません。これにより、行が # で始まるファイル/メッセージコンテンツを安全にインポートできます。

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

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

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

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

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

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

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

コマンドが入力ストリームから処理される際に、fast-import が progress 行全体を自身の標準出力チャネル (ファイルディスクリプタ 1) に変更せずにそのまま出力するようにします。このコマンドは、現在のインポートや fast-import の内部状態には影響を与えません。

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

checkpoint の直後に progress コマンドを配置すると、checkpoint がいつ完了し、fast-import が更新した参照に安全にアクセスできるかを読者に通知します。

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

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

fast-import が、以前に --cat-blob-fd 引数で設定されたファイルディスクリプタに BLOB を出力するようにします。このコマンドは、現在のインポートには影響しません。その主な目的は、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は、実際の使用状況では決して見られない、最適とは言えないパックファイルを出力します。

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

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

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,000以上のブランチと45,114以上のファイルを持つプロジェクトを非常に限られたメモリフットプリント（アクティブなブランチあたり2.7 MiB未満）で効率的にインポートすることを可能にします。