SYNOPSIS

git fast-export [<options>] | git fast-import

DESCRIPTION

このプログラムは、指定されたリビジョンを git fast-import にパイプするのに適した形式でダンプします。

人間が読める形式のバンドル置換として(linkgit：git-bundle[1] 参照)、または履歴の書き換えを行うために git fast-import にフィードする前に編集できる形式として使用できます(git filter-repo などのツールの能力に依存します)。

OPTIONS

--progress=<n>

インポート中に git fast-import で表示されるように、<n>オブジェクトごとに progress ステートメントを挿入します。

--signed-tags=(verbatim|warn-verbatim|warn-strip|strip|abort)

Specify how to handle signed tags. Since any transformation after the export (or during the export, such as excluding revisions) can change the hashes being signed, the signatures may become invalid.

When asking to abort (which is the default), this program will die when encountering a signed tag. With strip, the tags will silently be made unsigned, with warn-strip they will be made unsigned but a warning will be displayed, with verbatim, they will be silently exported and with warn-verbatim (or warn, a deprecated synonym), they will be exported, but you will see a warning. verbatim and warn-verbatim should only be used if you know that no transformation affecting tags or any commit in their history will be performed by you or by fast-export or fast-import, or if you do not care that the resulting tag will have an invalid signature.

--signed-commits=(verbatim|warn-verbatim|warn-strip|strip|abort)

Specify how to handle signed commits. Behaves exactly as --signed-tags, but for commits. Default is strip, which is the same as how earlier versions of this command without this option behaved.

When exported, a signature starts with:

gpgsig <git-hash-algo> <signature-format>

where <git-hash-algo> is the Git object hash so either "sha1" or "sha256", and <signature-format> is the signature type, so "openpgp", "x509", "ssh" or "unknown".

For example, an OpenPGP signature on a SHA-1 commit starts with gpgsig sha1 openpgp, while an SSH signature on a SHA-256 commit starts with gpgsig sha256 ssh.

While all the signatures of a commit are exported, an importer may choose to accept only some of them. For example git-fast-import(1) currently stores at most one signature per Git hash algorithm in each commit.

Note
 This is highly experimental and the format of the data stream may change in the future without compatibility guarantees.
--tag-of-filtered-object=(abort|drop|rewrite)

タグ付けされたオブジェクトが除外される、タグの処理方法を指定します。 エクスポートするリビジョンとファイルはパスによって制限される可能性があるため、タグ付けされたオブジェクトは完全にフィルタリングされる可能性があります。

abort (デフォルト)を指定すると、このプログラムはそのようなタグに遭遇すると終了(die)します。 drop を指定すると、そのようなタグが出力から省略されます。 rewrite を指定すると、タグ付けされたオブジェクトがコミットの場合、タグを書き換えて祖先のコミットにタグを付けます(親の書き換えをにより; git-rev-list(1) 参照)。

-M
-C

git-diff(1) のマニュアルページで説明されているように、移動 および/または コピーの検出を実行し、それを使用して、出力ダンプに rename および copy コマンドを生成します。

注意: これらのオプションを指定した場合、このコマンドの以前のバージョンは警告を出さずに誤った結果を生成することに注意してください。

--export-marks=<file>

完了すると、内部マークテーブルを <file> にダンプします。 マークは1行に1つずつ :markid SHA-1 として書き込まれます。 リビジョンのマークのみがダンプされます。 ブロブのマークは無視されます。 バックエンドはこのファイルを使用して、インポートが完了した後にインポートを検証したり、増分実行(incremental runs)全体でマークテーブルを保存したりできます。 <file> は完了時にのみ開かれ、切り詰め(truncate)られるため、 同じパスを --import-marks に安全に指定することもできます。 新しいオブジェクトが マーク/エクスポート されていない場合、ファイルへは書き込まれません。

--import-marks=<file>

入力を処理する前に、<file>で指定されたマークをロードします。 入力ファイルは存在し、読み取り可能であり、 --export-marks によって生成されたものと同じ形式を使用する必要があります。

--mark-tags

マークIDでブロブとコミットにラベルを付けることに加えて、タグにもラベルを付けます。 これは、 --export-marks および --import-marks と組み合わせて使用すると便利です。また、ネストされたタグのエクスポートにも役立ちます(そして必要です)。 それは他のケースを損なうことはなく、デフォルトになりえますが、多くのfast-importフロントエンドは、マーク識別子を持つタグを受け入れる準備ができていません。

すでにマークされているコミット(またはタグ)は、再度エクスポートされません。 バックエンドが同様の --import-marks ファイルを使用する場合、これにより、複数実行に渡ってマークを同一に保つことにより、リポジトリの増分双方向エクスポートが可能になります。

--fake-missing-tagger

一部の古いリポジトリには、taggerのないタグがあります。 fast-importプロトコルはそれについてかなり厳格であり、それを許可しません。 したがって、出力を高速にインポートできるように、taggerを偽造します。

--use-done-feature

feature done 句(stanza)でストリームを開始し、 done コマンドで終了します。

--no-data

ブロブオブジェクトの出力をスキップし、代わりに元のSHA-1ハッシュを介してブロブを参照します。 これは、個々のファイルの内容に触れることなく、リポジトリのディレクトリ構造または履歴を書き換える場合に役立ちます。 結果のストリームは、必要なオブジェクトがすでに含まれているリポジトリでのみ使用できることに注意してください。

--full-tree

このオプションにより、fast-exportは、コミットごとに deleteall ディレクティブを発行し、その後にコミット内のすべてのファイルの完全なリストを発行します(コミットの最初の親とは異なるファイルをリストするだけではありません)。

--anonymize

履歴と保存されたツリーの形を維持しながら、リポジトリのコンテンツを匿名化(anonymize)します。 以下の「ANONYMIZING」のセクションを参照してください。

--anonymize-map=<from>[:<to>]

匿名化(anonymized)された出力でトークン <from> を <to> に変換します。 <to> を省略した場合は、 <from> をそれ自体にマップします(つまり、匿名化しません)。 以下の「ANONYMIZING」セクションを参照してください。

--reference-excluded-parents

デフォルトでは、 git fast-export master~5..master などのコマンドを実行すると、コミット master~5 が含まれなくなり、master~4 の親として master~5 がなくなります( ただし、古い master~4 と 新しい master~4 の両方に同じファイルがあります)。 --reference-excluded-parents を使用して、代わりに、sha1sum によって除外された履歴範囲内のコミットをストリームに参照させます。 結果のストリームは、必要な親コミットがすでに含まれているリポジトリでのみ使用できることに注意してください。

--show-original-ids

コミットとブロブの出力に追加のディレクティブ original-oid <SHA1SUM> を追加します。 このようなディレクティブは git-fast-import などのインポーターによって無視される可能性がありますが、中間フィルター(たとえば、古いコミットを参照するコミットメッセージの書き換え、またはIDによるブロブの削除)に役立つ場合があります。

--reencode=(yes|no|abort)

コミット・オブジェクトで encoding ヘッダーを処理する方法を指定します。 abort (デフォルト)を指定すると、 このプログラムはそのようなコミット・オブジェクトに遭遇すると終了(die)します。 yes を指定すると、 コミット・メッセージが UTF-8 に再エンコードされます。 no を指定すると、 元のエンコーディングが保持されます。

--refspec

指定されたrefspecをエクスポートされた各refに適用します。複数指定することができます。

[<git-rev-list-args>…]

エクスポートする特定のオブジェクトと参照を指定する、 git rev-parse および git rev-list に受け入れられる引数のリスト。 たとえば、 master~10..master を使用すると、現在のmaster参照が、10番目の祖先のコミット以降に追加されたすべてのオブジェクト、および (--reference-excluded-parentsオプションが指定されていない場合、) master~9 と master~10 に共通のすべてのファイルとともにエクスポートされます。

EXAMPLES

$ git fast-export --all | (cd /empty/repository && git fast-import)

これにより、リポジトリ全体がエクスポートされ、既存の空のリポジトリにインポートされます。 UTF-8でないコミットの再エンコードを除いて、1対1のミラーになります。

$ git fast-export master~5..master |
        sed "s|refs/heads/master|refs/heads/other|" |
        git fast-import

これにより、 master~5..master から other という新しいブランチが作成されます(つまり、 master に線形履歴がある場合は、最後の5回のコミットが必要になります)。

注意: これは、そのリビジョン範囲によって参照されるブロブとコミットメッセージのいずれにも文字列 refs/heads/master が含まれていないことを前提としていることに注意してください。

ANONYMIZING(匿名化)

--anonymize オプションが指定されている場合、gitは、いくつかのバグを再現するのに十分な元のツリーと履歴パターンを保持しながら、リポジトリからすべての識別情報(identifying information)を削除しようとします。 その目標は、プライベートリポジトリで見つかったgitバグが匿名化されたリポジトリに残り、匿名化されたリポジトリをgit開発者と共有してバグの解決に役立てることです。

このオプションを使用すると、gitは、出力内のすべての refname、パス、ブロブコンテンツ、コミットメッセージ、タグメッセージ、名前、電子メールアドレス を匿名化されたデータに置き換えます。 同じ文字列の2つのインスタンスは同等に置き換えられます(たとえば、同じ作者による2つのコミットは、出力に同じ匿名の作者が含まれますが、元の作者文字列とは類似していません)。 コミット、ブランチ、タグの関係、コミット のタイムスタンプは保持されます(ただし、コミットメッセージとrefnameは元のメッセージとは似ていません)。 ツリーの相対的な構成は保持されますが(たとえば、10個のファイルと3個のツリーを持つルートツリーがある場合、出力も保持されます)、それらの名前とファイルの内容は置き換えられます。

あなたがgitのバグを見つけたと思う場合は、リポジトリ全体の匿名化されたストリームをエクスポートすることから始めることができます:

$ git fast-export --anonymize --all >anon-stream

次に、そのストリームから作成されたリポジトリでバグが持続することを確認します(多くのバグは、リポジトリの正確な内容に依存しているため、持続しません):

$ git init anon-repo
$ cd anon-repo
$ git fast-import <../anon-stream
$ ... test your bug ...

匿名化されたリポジトリにバグが表示されている場合は、通常のバグレポートと一緒に anon-stream を共有する価値があるかもしれません。 匿名化されたストリームは非常によく圧縮されるため、gzipすることをお勧めします。ストリームを調べてプライベートデータが含まれていないことを確認する場合は、送信する前にストリームを直接確認できます。 また、試してみることもできます:

$ perl -pe 's/\d+/X/g' <anon-stream | sort -u | less

これは、すべての一意の行を表示します("User 0"、 "User 1" などを "User X" に折りたたむために、数字を "X" に変換します)。 これにより、出力がはるかに小さくなり、通常、ストリームにプライベートデータがないことをすばやく確認するのは簡単です。

一部のバグを再現するには、特定のコミットまたはパスを参照する必要がある場合があります。これは、refnameおよびパスが匿名化された後に困難になります。 特定のトークンをそのままにするか、新しい値にマップするように要求できます。 たとえば、 git rev-list sensitive -- secret.c で再現されるバグがある場合は、以下のコマンドを実行できます:

$ git fast-export --anonymize --all \
      --anonymize-map=sensitive:foo \
      --anonymize-map=secret.c:bar.c \
      >stream

ストリームをインポートした後、匿名化されたリポジトリで git rev-list foo -- bar.c を実行できます。

注意: パスとrefnameは、スラッシュ(/)境界でトークンに分割されることに注意してください。 上記のコマンドは、 subdir/secret.c を path123/bar.c のようなものとして匿名化します。 次に、あなたは匿名化されたリポジトリで bar.c を検索して、最終的なパス名を決定できます。

最終パス名の参照を簡単にするために、各パスコンポーネントをマップできます。 したがって、subdir も publicdir に匿名化すると、最終的なパス名は publicdir/bar.c になります。

LIMITATIONS

git fast-import はツリーにタグを付けることができないため、コミットではなくツリーを参照するタグが含まれている linux.git リポジトリを完全にエクスポートすることはできません。

SEE ALSO

git-fast-import(1)

GIT

Part of the git(1) suite