fast-import

NAME

git-fast-import - Backend for fast Git data importersgit-fast-import - 高速Gitデータインポーターのバックエンド

SYNOPSIS概要

frontend | git fast-import [<options>]

DESCRIPTION説明

This program is usually not what the end user wants to run directly. Most end users want to use one of the existing frontend programs, which parses a specific type of foreign source and feeds the contents stored there to git fast-import.このプログラムは通常、エンドユーザーが直接実行したいものではありません。ほとんどのエンドユーザーは、特定の種類の外部ソースを解析してそこに格納されているコンテンツをフィードして高速インポートを実現する、既存のフロントエンドプログラムの1つを使用したいと考えています。

fast-import reads a mixed command/data stream from standard input and writes one or more packfiles directly into the current repository. When EOF is received on standard input, fast import writes out updated branch and tag refs, fully updating the current repository with the newly imported data.fast-importは、標準入力からコマンドとデータが混在するストリームを読み込み、1つ以上のパックファイルを現在のリポジトリに直接書き込みます。EOFが標準入力で受け取られると、高速インポートは更新されたブランチとタグ参照を書き出し、現在のリポジトリを新しくインポートされたデータで完全に更新します。

The fast-import backend itself can import into an empty repository (one that has already been initialized by git init) or incrementally update an existing populated repository. Whether or not incremental imports are supported from a particular foreign source depends on the frontend program in use.高速インポートバックエンド自体は、空のリポジトリ(git initによって既に初期化されているもの)にインポートすることも、既存の移入されたリポジトリを徐々に更新することもできます。増分インポートが特定の外部ソースからサポートされているかどうかは、使用中のフロントエンドプログラムによって異なります。

OPTIONSオプション

--force - 力

Force updating modified existing branches, even if doing so would cause commits to be lost (as the new commit does not contain the old commit).変更された既存のブランチを強制的に更新すると、コミットが失われる可能性がある場合でも(新しいコミットに古いコミットが含まれていないため)。

--quiet - 静か

Disable the output shown by --stats, making fast-import usually be silent when it is successful. However, if the import stream has directives intended to show user output (e.g. progress directives), the corresponding messages will still be shown.--statsで表示される出力を無効にします。通常、高速インポートは成功したときには表示されません。ただし、インポートストリームにユーザー出力を表示するためのprogressディレクティブ(ディレクティブなど)が含まれている場合でも、対応するメッセージは表示されます。

--stats - スタッツ

Display some basic statistics about the objects fast-import has created, the packfiles they were stored into, and the memory used by fast-import during this run. Showing this output is currently the default, but can be disabled with --quiet.高速インポートによって作成されたオブジェクト、それらが格納されたパックファイル、およびこの実行中に高速インポートによって使用されたメモリに関するいくつかの基本的な統計を表示します。この出力を表示することは現在デフォルトですが、--quietで無効にすることができます。

Options for Frontendsフロントエンドのオプション

--cat-blob-fd=<fd> --cat-blob-fd = <fd>

Write responses to get-mark, cat-blob, and ls queries to the file descriptor <fd> instead of stdout. Allows progress output intended for the end-user to be separated from other output.回答への書き込みget-markcat-blobおよびlsファイルディスクリプタ<FD>の代わりにクエリをstdout。可能にするprogressエンドユーザのために意図出力が他の出力から分離されます。

--date-format=<fmt> --date-format = <fmt>

Specify the type of dates the frontend will supply to fast-import within author, committer and tagger commands. See “Date Formats” below for details about which formats are supported, and their syntax.フロントエンドは内での高速インポートに供給する日付の種類を指定しauthorcommitterそしてtaggerコマンドを。サポートされている形式とその構文の詳細については、下記の「日付形式」を参照してください。

--done - 完了

Terminate with error if there is no done command at the end of the stream. This option might be useful for detecting errors that cause the frontend to terminate before it has started to write a stream.doneストリームの最後にコマンドがない場合はエラーで終了します。このオプションは、フロントエンドがストリームの書き込みを開始する前にフロントエンドを終了させる原因となるエラーを検出するのに役立ちます。

Locations of Marks Filesマークファイルの場所

--export-marks=<file> --export-marks = <ファイル>

Dumps the internal marks table to <file> when complete. Marks are written one per line as :markid SHA-1. Frontends can use this file to validate imports after they have been completed, or to save the marks table across incremental runs. As <file> is only opened and truncated at checkpoint (or completion) the same path can also be safely given to --import-marks.完了すると、内部マークテーブルを<file>にダンプします。マークは1行に1つずつ書かれてい:markid SHA-1ます。フロントエンドはこのファイルを使用して、インポートが完了した後にインポートを検証したり、増分実行にわたってマークテーブルを保存したりできます。<file>はチェックポイント(または完了)時に開かれ切り捨てられるだけなので、同じパスを--import-marksに安全に指定することもできます。

--import-marks=<file> --import-marks = <ファイル>

Before processing any input, load the marks specified in <file>. The input file must exist, must be readable, and must use the same format as produced by --export-marks. Multiple options may be supplied to import more than one set of marks. If a mark is defined to different values, the last file wins.入力を処理する前に、<file>で指定されたマークをロードしてください。入力ファイルが存在し、読み取り可能でなければならず、--export-marksによって生成されたものと同じフォーマットを使用しなければなりません。複数のマークをインポートするために複数のオプションを指定できます。マークが異なる値に定義されている場合は、最後のファイルが優先されます。

--import-marks-if-exists=<file> --import-marks-if-exists = <ファイル>

Like --import-marks but instead of erroring out, silently skips the file if it does not exist.--import-marksと似ていますが、エラーが発生するのではなく、ファイルが存在しない場合は静かにスキップします。

--[no-]relative-marks - [no-]相対マーク

After specifying --relative-marks the paths specified with --import-marks= and --export-marks= are relative to an internal directory in the current repository. In git-fast-import this means that the paths are relative to the .git/info/fast-import directory. However, other importers may use a different location.--relative-marksを指定した後の--import-marks =および--export-marks =で指定されたパスは、現在のリポジトリ内の内部ディレクトリに対する相対パスです。git-fast-importでは、これはパスが.git / info / fast-importディレクトリからの相対パスであることを意味します。ただし、他の輸入業者は別の場所を使用することがあります。

Relative and non-relative marks may be combined by interweaving --(no-)-relative-marks with the --(import|export)-marks= options.相対マークと非相対マークは、 - (no ?? - ) - 相対マークと - (import | export)-marks =オプションを織り交ぜて組み合わせることができます。

Performance and Compression Tuningパフォーマンスと圧縮の調整

--active-branches=<n> --active-branches = <n>

Maximum number of branches to maintain active at once. See “Memory Utilization” below for details. Default is 5.一度にアクティブに維持するブランチの最大数。詳細については、下記の「メモリ使用率」を参照してください。デフォルトは5です。

--big-file-threshold=<n> --big-file-threshold = <n>

Maximum size of a blob that fast-import will attempt to create a delta for, expressed in bytes. The default is 512m (512 MiB). Some importers may wish to lower this on systems with constrained memory.高速インポートがデルタの作成を試みるBLOBの最大サイズ(バイト単位)。デフォルトは512メートル(512 MiB)です。一部の輸入者は、メモリが制限されているシステムでこれを下げたいと思うかもしれません。

--depth=<n> --depth = <n>

Maximum delta depth, for blob and tree deltification. Default is 50.ブロブとツリーの細分化のための最大デルタ深度。デフォルトは50です。

--export-pack-edges=<file> --export-pack-edges = <ファイル>

After creating a packfile, print a line of data to <file> listing the filename of the packfile and the last commit on each branch that was written to that packfile. This information may be useful after importing projects whose total object set exceeds the 4 GiB packfile limit, as these commits can be used as edge points during calls to git pack-objects.パックファイルを作成した後、パックファイルのファイル名とそのパックファイルに書き込まれた各ブランチの最後のコミットをリストしたデータ行を<file>に出力します。この情報は、オブジェクトセットの合計が4 GiBパックファイルの制限を超えるプロジェクトをインポートした後に役立つことがあります。これらのコミットはgit pack-objectsの呼び出し中にエッジポイントとして使用できるためです

--max-pack-size=<n> --max-pack-size = <n>

Maximum size of each output packfile. The default is unlimited.各出力パックファイルの最大サイズ。デフォルトは無制限です。

fastimport.unpackLimit

See git-config[1]git-config [1]を見てください

PERFORMANCE性能

The design of fast-import allows it to import large projects in a minimum amount of memory usage and processing time. Assuming the frontend is able to keep up with fast-import and feed it a constant stream of data, import times for projects holding 10+ years of history and containing 100,000+ individual commits are generally completed in just 1-2 hours on quite modest (~$2,000 USD) hardware.高速インポートの設計により、最小限のメモリ使用量と処理時間で大規模プロジェクトをインポートできます。フロントエンドが速いインポートに追いついてそれに一定のデータの流れを供給することができると仮定すると、10年以上の歴史を持ち、100,000を超える個々のコミットを含むプロジェクトのインポート時間は、通常1〜2時間でかなり控えめに完了します。 〜2,000ドル)ハードウェア。

Most bottlenecks appear to be in foreign source data access (the source just cannot extract revisions fast enough) or disk IO (fast-import writes as fast as the disk will take the data). Imports will run faster if the source data is stored on a different drive than the destination Git repository (due to less IO contention).ほとんどのボトルネックは、外部ソースデータアクセス(ソースはリビジョンを十分な速さで抽出することができない)またはディスクIO(ディスクがデータを取得するのと同じくらいの速さで高速インポート書き込み)にあるようです。ソースデータが宛先Gitリポジトリとは異なるドライブに格納されている場合、インポートはより速く実行されます(IO競合が少ないため)。

DEVELOPMENT COST開発費

A typical frontend for fast-import tends to weigh in at approximately 200 lines of Perl/Python/Ruby code. Most developers have been able to create working importers in just a couple of hours, even though it is their first exposure to fast-import, and sometimes even to Git. This is an ideal situation, given that most conversion tools are throw-away (use once, and never look back).高速インポートのための典型的なフロントエンドは、Perl / Python / Rubyコードの約200行に達する傾向があります。ほとんどの開発者は、たった数時間で実用的なインポーターを作成することができました。たとえそれがファーストインポートに対する、そして時にはGitに対する最初のエクスポージャーであってもです。これは理想的な状況です。ほとんどの変換ツールは使い捨てになっているからです(一度だけ使用し、決して振り返らないでください)。

PARALLEL OPERATION並行操作

Like git push or git fetch, imports handled by fast-import are safe to run alongside parallel git repack -a -d or git gc invocations, or any other Git operation (including git prune, as loose objects are never used by fast-import).同様のgitのプッシュgitのフェッチ、高速インポートが取り扱う輸入はパラレルと一緒に実行しても安全ですgit repack -a -dgit gc(を含む呼び出し、または任意の他のGitの操作のgitプルーン緩いオブジェクトは高速インポートで使用されることはありませんように、)。

fast-import does not lock the branch or tag refs it is actively importing. After the import, during its ref update phase, fast-import tests each existing branch ref to verify the update will be a fast-forward update (the commit stored in the ref is contained in the new history of the commit to be written). If the update is not a fast-forward update, fast-import will skip updating that ref and instead prints a warning message. fast-import will always attempt to update all branch refs, and does not stop on the first failure.fast-importはブランチをロックしませんし、アクティブにインポートしているタグを参照します。インポート後、そのref更新フェーズの間に、高速インポートは既存の各ブランチrefをテストして、更新が早送り更新になることを確認します(refに格納されたコミットは、書き込まれるコミットの新しい履歴に含まれます)。更新が早送り更新ではない場合、早送りはその参照の更新をスキップし、代わりに警告メッセージを表示します。fast-importは常に全てのブランチ参照を更新しようとします、そして最初の失敗で止まりません。

Branch updates can be forced with --force, but it’s recommended that this only be used on an otherwise quiet repository. Using --force is not necessary for an initial import into an empty repository.ブランチの更新は--forceで強制することができますが、それ以外は静かなリポジトリでのみ使用することをお勧めします。空のリポジトリへの最初のインポートに--forceを使用する必要はありません。

TECHNICAL DISCUSSION技術的な議論

fast-import tracks a set of branches in memory. Any branch can be created or modified at any point during the import process by sending a commit command on the input stream. This design allows a frontend program to process an unlimited number of branches simultaneously, generating commits in the order they are available from the source data. It also simplifies the frontend programs considerably.fast-importはメモリ内の一連のブランチを追跡します。commit入力ストリームでコマンドを送信することによって、インポートプロセス中の任意の時点で、任意のブランチを作成または変更できます。この設計により、フロントエンドプログラムは無制限の数のブランチを同時に処理し、ソースデータから利用可能な順序でコミットを生成することができます。それはまたフロントエンドプログラムをかなり単純化します。

fast-import does not use or alter the current working directory, or any file within it. (It does however update the current Git repository, as referenced by GIT_DIR.) Therefore an import frontend may use the working directory for its own purposes, such as extracting file revisions from the foreign source. This ignorance of the working directory also allows fast-import to run very quickly, as it does not need to perform any costly file update operations when switching between branches.fast-importは現在の作業ディレクトリ、またはその中のファイルを使用または変更しません。(しかしながら、それによって参照されるように、それは現在のGitリポジトリを更新するGIT_DIR。)したがって、インポートフロントエンドは、外部ソースからファイルリビジョンを抽出するなど、それ自身の目的のために作業ディレクトリを使用することができる。作業ディレクトリをこのように無視しても、ブランチ間の切り替え時にコストのかかるファイル更新操作を実行する必要がないため、高速インポートを非常に迅速に実行できます。

INPUT FORMAT入力フォーマット

With the exception of raw file data (which Git does not interpret) the fast-import input format is text (ASCII) based. This text based format simplifies development and debugging of frontend programs, especially when a higher level language such as Perl, Python or Ruby is being used.生のファイルデータ(Gitは解釈しません)を除いて、高速インポートの入力フォーマットはテキスト(ASCII)ベースです。このテキストベースのフォーマットは、特にPerl、Python、Rubyなどの高級言語が使用されている場合に、フロントエンドプログラムの開発とデバッグを単純化します。

fast-import is very strict about its input. Where we say SP below we mean exactly one space. Likewise LF means one (and only one) linefeed and HT one (and only one) horizontal tab. Supplying additional whitespace characters will cause unexpected results, such as branch names or file names with leading or trailing spaces in their name, or early termination of fast-import when it encounters unexpected input.高速インポートはその入力に関して非常に厳密です。以下のSPを言うところでは、我々はまさに一つのスペースを意味します。同様にLFは1つ(そして1つだけ)の改行とHT(1つだけ)の水平タブを意味します。追加の空白文字を指定すると、名前に先頭または末尾のスペースが含まれているブランチ名やファイル名、予期しない入力が発生したときのfast-importの早期終了など、予期しない結果が発生します。

Stream Commentsストリームコメント

To aid in debugging frontends fast-import ignores any line that begins with # (ASCII pound/hash) up to and including the line ending LF. A comment line may contain any sequence of bytes that does not contain an LF and therefore may be used to include any detailed debugging information that might be specific to the frontend and useful when inspecting a fast-import data stream.フロントエンドのデバッグを支援するために、fast-importは#(ASCIIポンド/ハッシュ)で始まる行末までを無視しますLF。コメント行には、LFを含まない任意のバイトシーケンスを含めることができます。したがって、フロントエンドに固有で高速インポートデータストリームを検査するときに役立つ可能性がある詳細なデバッグ情報を含めるために使用できます。

Date Formats日付フォーマット

The following date formats are supported. A frontend should select the format it will use for this import by passing the format name in the --date-format=<fmt> command-line option.以下の日付フォーマットがサポートされています。フロントエンドは、 - date-format = <fmt>コマンドラインオプションでフォーマット名を渡すことによって、このインポートに使用するフォーマットを選択する必要があります。

raw

This is the Git native format and is <time> SP <offutc>. It is also fast-import’s default format, if --date-format was not specified.これはGitのネイティブフォーマットです<time> SP <offutc>。--date-formatが指定されていない場合は、これもfast-importのデフォルトフォーマットです。

The time of the event is specified by <time> as the number of seconds since the UNIX epoch (midnight, Jan 1, 1970, UTC) and is written as an ASCII decimal integer.イベントの時刻は、<time>UNIXエポックからの経過秒数(1970年1月1日午前0時、UTC)で指定され、ASCII 10進整数として書き込まれます。

The local offset is specified by <offutc> as a positive or negative offset from UTC. For example EST (which is 5 hours behind UTC) would be expressed in <tz> by “-0500” while UTC is “+0000”. The local offset does not affect <time>; it is used only as an advisement to help formatting routines display the timestamp.ローカルオフセットは<offutc>、UTCからの正または負のオフセットとして指定されます。たとえば、EST(UTCより5時間<tz>遅い)は「-0500」で表され、UTCは「+0000」です。ローカルオフセットは影響しません<time>。これは、書式設定ルーチンがタイムスタンプを表示するのを助けるためのアドバイスとしてのみ使用されます。

If the local offset is not available in the source material, use “+0000”, or the most common local offset. For example many organizations have a CVS repository which has only ever been accessed by users who are located in the same location and time zone. In this case a reasonable offset from UTC could be assumed.ローカルオフセットがソース素材で利用できない場合は、“ + 0000”、または最も一般的なローカルオフセットを使用してください。たとえば、多くの組織には、同じ場所とタイムゾーンにいるユーザーによってしかアクセスされなかったCVSリポジトリがあります。この場合、UTCからの妥当なオフセットが想定されます。

Unlike the rfc2822 format, this format is very strict. Any variation in formatting will cause fast-import to reject the value.rfc2822フォーマットとは異なり、このフォーマットは非常に厳密です。書式設定に違いがあると、高速インポートで値が拒否されます。

rfc2822

This is the standard email format as described by RFC 2822.これは、RFC 2822で説明されている標準の電子メール形式です。

An example value is “Tue Feb 6 11:22:18 2007 -0500”. The Git parser is accurate, but a little on the lenient side. It is the same parser used by git am when applying patches received from email.値の例は“ Tue Feb 6 11:22:18 2007 -0500”です。Gitパーサは正確ですが、少し寛大な面があります。これは、電子メールから受け取ったパッチを適用するときにgit amによって使用されるものと同じパーサーです

Some malformed strings may be accepted as valid dates. In some of these cases Git will still be able to obtain the correct date from the malformed string. There are also some types of malformed strings which Git will parse wrong, and yet consider valid. Seriously malformed strings will be rejected.不正な形式の文字列が有効な日付として受け入れられることがあります。これらの場合のいくつかにおいて、Gitは依然として不正な形式の文字列から正しい日付を取得することができます。Gitが間違って解析し、それでも有効だと考える形式の文字列もあります。深刻な形式の文字列は拒否されます。

Unlike the raw format above, the time zone/UTC offset information contained in an RFC 2822 date string is used to adjust the date value to UTC prior to storage. Therefore it is important that this information be as accurate as possible.raw上記の形式とは異なり、RFC 2822の日付文字列に含まれるタイムゾーン/ UTCオフセット情報は、保存前に日付値をUTCに調整するために使用されます。したがって、この情報ができるだけ正確であることが重要です。

If the source material uses RFC 2822 style dates, the frontend should let fast-import handle the parsing and conversion (rather than attempting to do it itself) as the Git parser has been well tested in the wild.ソース資料がRFC 2822スタイルの日付を使用している場合、Gitパーサーは野外で十分にテストされているので、フロントエンドは(それ自体を試みるのではなく)高速インポートに解析と変換を処理させるべきです。

Frontends should prefer the raw format if the source material already uses UNIX-epoch format, can be coaxed to give dates in that format, or its format is easily convertible to it, as there is no ambiguity in parsing.rawソース資料がすでにUNIXエポック形式を使用している場合、その形式で日付を指定するように同軸化できる場合、または構文解析にあいまいさがないため、形式を簡単に変換できる場合は、フロントエンドで形式を選択します。

now

Always use the current time and time zone. The literal now must always be supplied for <when>.常に現在の時刻とタイムゾーンを使用してください。リテラルnowは常に指定する必要があります<when>

This is a toy format. The current time and time zone of this system is always copied into the identity string at the time it is being created by fast-import. There is no way to specify a different time or time zone.これはおもちゃのフォーマットです。このシステムの現在の時間とタイムゾーンは、高速インポートによって作成されるときに、常に識別文字列にコピーされます。異なる時間またはタイムゾーンを指定する方法はありません。

This particular format is supplied as it’s short to implement and may be useful to a process that wants to create a new commit right now, without needing to use a working directory or git update-index.この特定のフォーマットは、実装するのが短いために提供されており、作業ディレクトリやgit update-indexを使用する必要なしに、今すぐ新しいコミットを作成したいプロセスにとって有用かもしれません。

If separate author and committer commands are used in a commit the timestamps may not match, as the system clock will be polled twice (once for each command). The only way to ensure that both author and committer identity information has the same timestamp is to omit author (thus copying from committer) or to use a date format other than now.システムクロックが2回ポーリングされるため(コマンドごとに1回)、別々のコマンドがコマンドで使用されているとタイムスタンプが一致しない場合がauthorありcommitterますcommit。作成者とコミッターの両方の識別情報が同じタイムスタンプを持つようにする唯一の方法は、省略することauthor(したがってコピー元committer)または以外の日付形式を使用することですnow

Commandsコマンド

fast-import accepts several commands to update the current repository and control the current import process. More detailed discussion (with examples) of each command follows later.fast-importは現在のリポジトリを更新し、現在のインポートプロセスを制御するためのいくつかのコマンドを受け付けます。各コマンドのより詳細な説明(例付き)は後に続きます。

commit

Creates a new branch or updates an existing branch by creating a new commit and updating the branch to point at the newly created commit.新しいコミットを作成し、新しく作成されたコミットを指すようにブランチを更新することによって、新しいブランチを作成するか、既存のブランチを更新します。

tag

Creates an annotated tag object from an existing commit or branch. Lightweight tags are not supported by this command, as they are not recommended for recording meaningful points in time.既存のコミットまたはブランチから注釈付きタグオブジェクトを作成します。軽量のタグは、このコマンドではサポートされていません。意味のある時点を記録するために推奨されていないためです。

reset

Reset an existing branch (or a new branch) to a specific revision. This command must be used to change a branch to a specific revision without making a commit on it.既存のブランチ(または新しいブランチ)を特定のリビジョンにリセットします。このコマンドは、コミットを行わずにブランチを特定のリビジョンに変更するために使用しなければなりません。

blob

Convert raw file data into a blob, for future use in a commit command. This command is optional and is not needed to perform an import.将来のcommitコマンドで使用するために、生のファイルデータをBLOBに変換します。このコマンドはオプションであり、インポートの実行には必要ありません。

checkpoint

Forces fast-import to close the current packfile, generate its unique SHA-1 checksum and index, and start a new packfile. This command is optional and is not needed to perform an import.高速インポートで現在のパックファイルをクローズし、その固有のSHA-1チェックサムとインデックスを生成して、新しいパックファイルを開始します。このコマンドはオプションであり、インポートの実行には必要ありません。

progress

Causes fast-import to echo the entire line to its own standard output. This command is optional and is not needed to perform an import.fast-importに行全体をそれ自身の標準出力にエコーさせます。このコマンドはオプションであり、インポートの実行には必要ありません。

done

Marks the end of the stream. This command is optional unless the done feature was requested using the --done command-line option or feature done command.ストリームの終わりを示します。このコマンドは、done機能が--doneコマンド行オプションまたはfeature doneコマンドを使用して要求されていない限り、オプションです。

get-mark

Causes fast-import to print the SHA-1 corresponding to a mark to the file descriptor set with --cat-blob-fd, or stdout if unspecified.マーク付きのSHA-1をで--cat-blob-fd、またはstdout指定されていない場合はファイルディスクリプタセットに出力します。

cat-blob

Causes fast-import to print a blob in cat-file --batch format to the file descriptor set with --cat-blob-fd or stdout if unspecified.指定されていない場合、または指定されていない場合は、fast-importは、BLOBをcat-file --batch形式でファイル記述子セットに出力します。--cat-blob-fdstdout

ls

Causes fast-import to print a line describing a directory entry in ls-tree format to the file descriptor set with --cat-blob-fd or stdout if unspecified.指定されていない場合、または指定されていない場合は、高速インポートでlsツリー形式のディレクトリー項目を記述する行をファイル記述子セットに印刷します。--cat-blob-fdstdout

feature

Enable the specified feature. This requires that fast-import supports the specified feature, and aborts if it does not.指定した機能を有効にします。これはfast-importが指定された機能をサポートすることを要求し、サポートしていない場合は打ち切ります。

option

Specify any of the options listed under OPTIONS that do not change stream semantic to suit the frontend’s needs. This command is optional and is not needed to perform an import.フロントエンドのニーズに合わせてストリームの意味を変更しない、OPTIONSの下にリストされているオプションのいずれかを指定します。このコマンドはオプションであり、インポートの実行には必要ありません。

commit

Create or update a branch with a new commit, recording one logical change to the project.プロジェクトへの論理的な変更を1つ記録して、新しいコミットでブランチを作成または更新します。

	'commit' SP <ref> LF
	mark?
	original-oid?
	('author' (SP <name>)? SP LT <email> GT SP <when> LF)?
	'committer' (SP <name>)? SP LT <email> GT SP <when> LF
	data
	('from' SP <commit-ish> LF)?
	('merge' SP <commit-ish> LF)?
	(filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)*
	LF?

where <ref> is the name of the branch to make the commit on. Typically branch names are prefixed with refs/heads/ in Git, so importing the CVS branch symbol RELENG-1_0 would use refs/heads/RELENG-1_0 for the value of <ref>. The value of <ref> must be a valid refname in Git. As LF is not valid in a Git refname, no quoting or escaping syntax is supported here.どこ<ref>にコミット作るブランチの名前です。通常ブランチ名はrefs/heads/Gitで接頭辞が付いているので、CVSブランチシンボルRELENG-1_0をインポートするrefs/heads/RELENG-1_0との値に使用されます<ref>。の値は<ref>Gitでは有効なrefnameでなければなりません。LFGitのもしrefnameでは有効ではありません、何の引用またはエスケープ構文は、ここでサポートされていません。

A mark command may optionally appear, requesting fast-import to save a reference to the newly created commit for future use by the frontend (see below for format). It is very common for frontends to mark every commit they create, thereby allowing future branch creation from any imported commit.markこのコマンドは、必要に応じて新たに作成された(形式については下記を参照)フロントエンドによって将来の使用のためにコミットへの参照を保存するために高速インポートを要求し、表示されることがあります。フロントエンドが作成したすべてのコミットにマークを付けることは非常に一般的です。これにより、インポートしたコミットから将来のブランチ作成が可能になります。

The data command following committer must supply the commit message (see below for data command syntax). To import an empty commit message use a 0 length data. Commit 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.data次のコマンドは、committer(下記参照コミットメッセージを供給しなければならないdataコマンドの構文)。空のコミットメッセージをインポートするには、長さ0のデータを使用します。コミットメッセージは自由形式であり、Gitでは解釈されません。高速インポートでは他のエンコーディングの指定が許可されていないため、現在はUTF-8でエンコードする必要があります。

Zero or more filemodify, filedelete, filecopy, filerename, filedeleteall and notemodify commands may be included to update the contents of the branch prior to creating the commit. These commands may be supplied in any order. However it is recommended that a filedeleteall command precede all filemodify, filecopy, filerename and notemodify commands in the same commit, as filedeleteall wipes the branch clean (see below).ゼロ以上filemodifyfiledeletefilecopyfilerenamefiledeleteallおよびnotemodifyコマンドは、前にコミット作成するブランチの内容を更新するために含まれてもよいです。これらのコマンドは任意の順序で指定できます。しかし、することが推奨されfiledeleteallたコマンドがすべて先行しfilemodifyfilecopyfilerenamenotemodifyと、同じ内のコマンドがコミットfiledeleteall分岐が(下記参照)クリーンワイプ。

The LF after the command is optional (it used to be required).LFコマンドの後はオプションです(以前は必須でした)。

author

An author command may optionally appear, if the author information might differ from the committer information. If author is omitted then fast-import will automatically use the committer’s information for the author portion of the commit. See below for a description of the fields in author, as they are identical to committer.author著者情報はコミッターの情報と異なる可能性がある場合、コマンドは、必要に応じて、表示されることがあります。author省略した場合、fast-importはコミットの作者部分にコミッタの情報を自動的に使用します。のフィールドの説明については、authorと同じであるため、以下を参照してくださいcommitter

committer

The committer command indicates who made this commit, and when they made it.このcommitterコマンドは、誰がこのコミットを行ったのか、そしていつコミットしたのかを示します。

Here <name> is the person’s display name (for example “Com M Itter”) and <email> is the person’s email address (“cm@example.com”). LT and GT are the literal less-than (\x3c) and greater-than (\x3e) symbols. These are required to delimit the email address from the other fields in the line. Note that <name> and <email> are free-form and may contain any sequence of bytes, except LT, GT and LF. <name> is typically UTF-8 encoded.これ<name>は、その人の表示名(「Com M Itter」など)で<email>あり、その人の電子メールアドレス(「cm@example.com」)です。LTそしてGT、リテラルの小なり記号(\ x3c)と大なり記号(\ x3e)です。これらは、電子メールアドレスを行内の他のフィールドから区切るために必要です。<name>and <email>は自由形式でありLTGTand を除いて任意のバイトシーケンスを含むことができることに注意してくださいLF<name>通常はUTF-8でエンコードされています。

The time of the change is specified by <when> using the date format that was selected by the --date-format=<fmt> command-line option. See “Date Formats” above for the set of supported formats, and their syntax.変更の時刻は、 - <when>date-format = <fmt>コマンドラインオプションで選択された日付形式を使用して指定されます。サポートされている形式とその構文については、上記の「日付形式」を参照してください。

from

The from command is used to specify the commit to initialize this branch from. This revision will be the first ancestor of the new commit. The state of the tree built at this commit will begin with the state at the from commit, and be altered by the content modifications in this commit.fromコマンドがからこのブランチを初期化するためにコミットを指定するために使用されます。この改訂は、新しいコミットの最初の祖先となるでしょう。このコミットで構築されたツリーの状態は、fromコミット時の状態から始まり、このコミットの内容変更によって変更されます。

Omitting the from command in the first commit of a new branch will cause fast-import to create that commit with no ancestor. This tends to be desired only for the initial commit of a project. If the frontend creates all files from scratch when making a new branch, a merge command may be used instead of from to start the commit with an empty tree. Omitting the from command on existing branches is usually desired, as the current commit on that branch is automatically assumed to be the first ancestor of the new commit.from新しいブランチの最初のコミットでコマンドを省略すると、fast-importは先祖なしでそのコミットを作成します。これはプロジェクトの初期コミットのためだけに望まれる傾向があります。新しいブランチを作るときにフロントエンドがすべてのファイルを最初から作成する場合は、空のツリーでコミットを開始するmerge代わりにコマンドを使用することができますfromfromそのブランチでの現在のコミットが自動的に新しいコミットの最初の祖先であると想定されるので、既存のブランチでコマンドを省略するのが通常望ましいです。

As LF is not valid in a Git refname or SHA-1 expression, no quoting or escaping syntax is supported within <commit-ish>.LFGitもしrefnameまたはSHA-1の発現は有効ではありませんが、何の引用またはエスケープ構文は内でサポートされません<commit-ish>

Here <commit-ish> is any of the following:ここでは<commit-ish>、次のいずれかです:

  • The name of an existing branch already in fast-import’s internal branch table. If fast-import doesn’t know the name, it’s treated as a SHA-1 expression.高速インポートの内部ブランチテーブルに既に存在するブランチの名前。fast-importが名前を知らない場合、それはSHA-1式として扱われます。

  • A mark reference, :<idnum>, where <idnum> is the mark number.マーク参照。:<idnum>ここ<idnum>で、はマーク番号です。

    The reason fast-import uses : to denote a mark reference is this character is not legal in a Git branch name. The leading : makes it easy to distinguish between the mark 42 (:42) and the branch 42 (42 or refs/heads/42), or an abbreviated SHA-1 which happened to consist only of base-10 digits.fast-importが:マーク参照を示すために使用する理由は、この文字がGitブランチ名では無効であるためです。先頭に:付けると、マーク42(:42)と分岐42(42またはrefs/heads/42)、または10進数の数字のみで構成されている短縮形のSHA-1 を区別しやすくなります。

    Marks must be declared (via mark) before they can be used.マークmarkは、使用する前に(経由で)宣言する必要があります。

  • A complete 40 byte or abbreviated commit SHA-1 in hex.完全な40バイトまたは短縮コミットSHA-1(16進数)。

  • Any valid Git SHA-1 expression that resolves to a commit. See “SPECIFYING REVISIONS” in gitrevisions[7] for details.コミットを解決する任意の有効なGit SHA-1式。詳細はgitrevisions [7]の「リビジョンの指定」を参照のこと。

  • The special null SHA-1 (40 zeros) specifies that the branch is to be removed.特別なヌルSHA-1(40個のゼロ)は、分岐を除去することを指定します。

The special case of restarting an incremental import from the current branch value should be written as:現在のブランチの値から増分インポートを再開する特別な場合は、次のように書く必要があります。

	from refs/heads/branch^0

The ^0 suffix is necessary as fast-import does not permit a branch to start from itself, and the branch is created in memory before the from command is even read from the input. Adding ^0 will force fast-import to resolve the commit through Git’s revision parsing library, rather than its internal branch table, thereby loading in the existing value of the branch.^0接尾辞は、高速インポートは、それ自体から開始する枝を許可しないよう必要であり、前のブランチは、メモリ内に作成されたfromコマンドがさえ入力から読み込まれます。追加^0することで、高速インポートがその内部ブランチテーブルではなくGitのリビジョン解析ライブラリを通してコミットを解決することを強制し、それによってブランチの既存の値をロードします。

merge

Includes one additional ancestor commit. The additional ancestry link does not change the way the tree state is built at this commit. If the from command is omitted when creating a new branch, the first merge commit will be the first ancestor of the current commit, and the branch will start out with no files. An unlimited number of merge commands per commit are permitted by fast-import, thereby establishing an n-way merge.追加の先祖コミットが1つ含まれています。追加の祖先リンクは、このコミットでツリー状態が構築される方法を変更しません。場合はfrom、新しいブランチを作成するときに、コマンドが省略され、最初のmergeコミットは、現在の最初の祖先のコミットとなり、分岐なしのファイルでスタートします。merge高速インポートでは、コミットごとに無制限の数のコマンドが許可されているため、n-wayマージが確立されます。

Here <commit-ish> is any of the commit specification expressions also accepted by from (see above).ここで<commit-ish>またによって受け入れられコミット宣言式のいずれかがあるfrom(上記参照します)。

filemodify

Included in a commit command to add a new file or change the content of an existing file. This command has two different means of specifying the content of the file.commit新しいファイルを追加したり、既存のファイルの内容を変更するためのコマンドに含まれています。このコマンドには、ファイルの内容を指定する2つの異なる方法があります。

External data format 外部データフォーマット

The data content for the file was already supplied by a prior blob command. The frontend just needs to connect it.ファイルのデータ内容は、前のblobコマンドによってすでに提供されています。フロントエンドはそれを接続するだけです。

	'M' SP <mode> SP <dataref> SP <path> LF

Here usually <dataref> must be either a mark reference (:<idnum>) set by a prior blob command, or a full 40-byte SHA-1 of an existing Git blob object. If <mode> is 040000` then <dataref> must be the full 40-byte SHA-1 of an existing Git tree object or a mark reference set with --import-marks.これは通常、前のコマンドで設定され<dataref>たmark reference(:<idnum>)かblob、既存のGit blobオブジェクトの全40バイトのSHA-1でなければなりません。場合<mode>であり040000`、その後<dataref>、完全な40バイトのSHA-1、既存のGitツリーオブジェクトのまたはで設定マーク基準でなければなりません--import-marks

Inline data format インラインデータ形式

The data content for the file has not been supplied yet. The frontend wants to supply it as part of this modify command.ファイルのデータ内容はまだ提供されていません。フロントエンドはこの変更コマンドの一部としてそれを供給したいと思います。

	'M' SP <mode> SP 'inline' SP <path> LF
	data

See below for a detailed description of the data command.dataコマンドの詳細な説明については下記を参照してください。

In both formats <mode> is the type of file entry, specified in octal. Git only supports the following modes:どちらの形式で<mode>も、8進数で指定されたファイルエントリの種類です。Gitは以下のモードのみをサポートします。

  • 100644 or 644: A normal (not-executable) file. The majority of files in most projects use this mode. If in doubt, this is what you want.100644または644:通常の(実行不可能な)ファイル。ほとんどのプロジェクトの大部分のファイルはこのモードを使用します。疑いがあるなら、これはあなたが欲しいものです。

  • 100755 or 755: A normal, but executable, file.100755または755:通常の、しかし実行可能なファイル。

  • 120000: A symlink, the content of the file will be the link target.120000:シンボリックリンク。ファイルの内容がリンク先になります。

  • 160000: A gitlink, SHA-1 of the object refers to a commit in another repository. Git links can only be specified by SHA or through a commit mark. They are used to implement submodules.160000:オブジェクトのgitlink、SHA-1は他のリポジトリでのコミットを参照しています。Gitリンクは、SHAまたはコミットマークを通してのみ指定できます。それらはサブモジュールを実装するために使用されます。

  • 040000: A subdirectory. Subdirectories can only be specified by SHA or through a tree mark set with --import-marks.040000:サブディレクトリ サブディレクトリは、SHAによって、またはで設定されたツリーマークを通じてのみ指定できます--import-marks

In both formats <path> is the complete path of the file to be added (if not already existing) or modified (if already existing).どちらの形式で<path>も、追加するファイル(存在しない場合)または変更するファイル(存在する場合)の絶対パスです。

A <path> string must use UNIX-style directory separators (forward slash /), may contain any byte other than LF, and must not start with double quote (").<path>文字列は、(スラッシュUNIX形式のディレクトリ区切り文字を使用する必要があり/、以外の任意のバイトを含んでいてもよい)LF、および二重引用符(で始めることはできません")。

A path can use C-style string quoting; this is accepted in all cases and mandatory if the filename starts with double quote or contains LF. In C-style quoting, the complete name should be surrounded with double quotes, and any LF, backslash, or double quote characters must be escaped by preceding them with a backslash (e.g., "path/with\n, \\ and \" in it").パスはCスタイルの文字列引用符を使用できます。これはすべての場合に受け入れられ、ファイル名が二重引用符またはcontainsで始まる場合は必須ですLF。Cスタイルの引用では、完全な名前を二重引用符で囲む必要があります。またLF、円記号または二重引用符の文字は、その前に円記号を付けてエスケープする必要があります(例:)"path/with\n, \ and \" in it"

The value of <path> must be in canonical form. That is it must not:の値は<path>正規形でなければなりません。それはいけません:

  • contain an empty directory component (e.g. foo//bar is invalid),空のディレクトリコンポーネントが含まれている(例:foo//bar無効)

  • end with a directory separator (e.g. foo/ is invalid),ディレクトリの区切り文字で終了しfoo/ます(例:無効)

  • start with a directory separator (e.g. /foo is invalid),ディレクトリの区切り文字で始める(例:/foo無効)

  • contain the special component . or .. (e.g. foo/./bar and foo/../bar are invalid).特殊なコンポーネントを含む、.または..(たとえばfoo/./barfoo/../bar無効です)。

The root of the tree can be represented by an empty string as <path>.ツリーのルートは、のような空の文字列で表すことができます<path>

It is recommended that <path> always be encoded using UTF-8.<path>常にUTF-8を使用してエンコードすることをお勧めします。

filedelete

Included in a commit command to remove a file or recursively delete an entire directory from the branch. If the file or directory removal makes its parent directory empty, the parent directory will be automatically removed too. This cascades up the tree until the first non-empty directory or the root is reached.commitファイルを削除したり、ブランチからディレクトリ全体を再帰的に削除したりするコマンドに含まれています。ファイルまたはディレクトリの削除によってその親ディレクトリが空になった場合、その親ディレクトリも自動的に削除されます。これは、最初の空でないディレクトリまたはルートに達するまでツリーをカスケードします。

	'D' SP <path> LF

here <path> is the complete path of the file or subdirectory to be removed from the branch. See filemodify above for a detailed description of <path>.これ<path>はブランチから削除されるファイルまたはサブディレクトリの完全なパスです。の詳細についてはfilemodify上記を参照してください<path>

filecopy

Recursively copies an existing file or subdirectory to a different location within the branch. The existing file or directory must exist. If the destination exists it will be completely replaced by the content copied from the source.既存のファイルまたはサブディレクトリをブランチ内の別の場所に再帰的にコピーします。既存のファイルまたはディレクトリが存在している必要があります。コピー先が存在する場合は、コピー元からコピーされたコンテンツに完全に置き換えられます。

	'C' SP <path> SP <path> LF

here the first <path> is the source location and the second <path> is the destination. See filemodify above for a detailed description of what <path> may look like. To use a source path that contains SP the path must be quoted.ここで最初のもの<path>は発信元の場所、2番目の<path>ものは宛先です。見た目のfilemodify詳細については、上記を参照してください<path>。SPを含むソースパスを使用するには、パスを引用符で囲む必要があります。

A filecopy command takes effect immediately. Once the source location has been copied to the destination any future commands applied to the source location will not impact the destination of the copy.filecopyこのコマンドはすぐに有効になります。転送元の場所が転送先にコピーされると、転送元の場所に今後適用されるコマンドがコピーの転送先に影響を与えることはありません。

filerename

Renames an existing file or subdirectory to a different location within the branch. The existing file or directory must exist. If the destination exists it will be replaced by the source directory.既存のファイルまたはサブディレクトリの名前をブランチ内の別の場所に変更します。既存のファイルまたはディレクトリが存在している必要があります。宛先が存在する場合は、それがソースディレクトリに置き換えられます。

	'R' SP <path> SP <path> LF

here the first <path> is the source location and the second <path> is the destination. See filemodify above for a detailed description of what <path> may look like. To use a source path that contains SP the path must be quoted.ここで最初のもの<path>は発信元の場所、2番目の<path>ものは宛先です。見た目のfilemodify詳細については、上記を参照してください<path>。SPを含むソースパスを使用するには、パスを引用符で囲む必要があります。

A filerename command takes effect immediately. Once the source location has been renamed to the destination any future commands applied to the source location will create new files there and not impact the destination of the rename.filerenameこのコマンドはすぐに有効になります。ソースの場所が宛先に名前変更されると、それ以降ソースの場所に適用されたコマンドはそこに新しいファイルを作成し、名前の変更先には影響を与えません。

Note that a filerename is the same as a filecopy followed by a filedelete of the source location. There is a slight performance advantage to using filerename, but the advantage is so small that it is never worth trying to convert a delete/add pair in source material into a rename for fast-import. This filerename command is provided just to simplify frontends that already have rename information and don’t want bother with decomposing it into a filecopy followed by a filedelete.a は、ソース位置のfilerenameaにfilecopy続けてa と同じであることに注意してくださいfiledelete。使用filerenameすることにはわずかなパフォーマンス上の利点がありますが、その利点は非常に小さいため、高速インポートのためにソース素材の削除/追加ペアを名前変更に変換することを試みる価値はありません。このfilerenameコマンドは、すでに名前変更情報があり、それをaにfilecopy続けてaに分解することに煩わされたくないフロントエンドを単純化するためだけに提供されていfiledeleteます。

filedeleteall

Included in a commit command to remove all files (and also all directories) from the branch. This command resets the internal branch structure to have no files in it, allowing the frontend to subsequently add all interesting files from scratch.commitブランチからすべてのファイル(およびすべてのディレクトリ)を削除するコマンドに含まれています。このコマンドは内部のブランチ構造をリセットしてファイルを持たないようにします。これによりフロントエンドは後から興味のあるすべてのファイルを最初から追加することができます。

	'deleteall' LF

This command is extremely useful if the frontend does not know (or does not care to know) what files are currently on the branch, and therefore cannot generate the proper filedelete commands to update the content.このコマンドはフロントエンドが現在どのファイルがブランチ上にあるのかわからない(または知りたくない)ためfiledelete、内容を更新するための適切なコマンドを生成できない場合に非常に役立ちます。

Issuing a filedeleteall followed by the needed filemodify commands to set the correct content will produce the same results as sending only the needed filemodify and filedelete commands. The filedeleteall approach may however require fast-import to use slightly more memory per active branch (less than 1 MiB for even most large projects); so frontends that can easily obtain only the affected paths for a commit are encouraged to do so.正しい内容を設定するためにfiledeleteall続けて必要なfilemodifyコマンドを発行すると、必要なコマンドだけを送信した場合filemodifyと同じ結果になりfiledeleteます。filedeleteallただし、このアプローチでは、アクティブなブランチごとにわずかに多くのメモリを使用するために高速インポートが必要になる場合があります(ほとんどの大規模プロジェクトでも1 MiB未満)。そのため、影響を受けるパスのみを簡単に取得できるフロントエンドを使用することをお勧めします。

notemodify

Included in a commit <notes_ref> command to add a new note annotating a <commit-ish> or change this annotation contents. Internally it is similar to filemodify 100644 on <commit-ish> path (maybe split into subdirectories). It’s not advised to use any other commands to write to the <notes_ref> tree except filedeleteall to delete all existing notes in this tree. This command has two different means of specifying the content of the note.commit <notes_ref>注釈を付ける新しい注釈を追加し<commit-ish>たり、注釈の内容を変更したりするためのコマンドに含まれています。内部的には<commit-ish>pathのfilemodify 100644に似ています(サブディレクトリに分割されているかもしれません)。このツリーの既存のノートをすべて削除する<notes_ref>以外は、他のコマンドを使ってツリーに書き込むことはお勧めできませんfiledeleteall。このコマンドには、メモの内容を指定する2つの異なる方法があります。

External data format 外部データフォーマット

The data content for the note was already supplied by a prior blob command. The frontend just needs to connect it to the commit that is to be annotated.メモのデータ内容は、前のblobコマンドによってすでに提供されています。フロントエンドはアノテーションを付けるコミットにそれを結び付けるだけです。

	'N' SP <dataref> SP <commit-ish> LF

Here <dataref> can be either a mark reference (:<idnum>) set by a prior blob command, or a full 40-byte SHA-1 of an existing Git blob object.これは、前のコマンドで設定され<dataref>たmark reference(:<idnum>)かblob、既存のGit blobオブジェクトの全40バイトのSHA-1です。

Inline data format インラインデータ形式

The data content for the note has not been supplied yet. The frontend wants to supply it as part of this modify command.メモのデータ内容はまだ提供されていません。フロントエンドはこの変更コマンドの一部としてそれを供給したいと思います。

	'N' SP 'inline' SP <commit-ish> LF
	data

See below for a detailed description of the data command.dataコマンドの詳細な説明については下記を参照してください。

In both formats <commit-ish> is any of the commit specification expressions also accepted by from (see above).どちらの形式<commit-ish>でも、コミット仕様式のいずれかで受け入れられていますfrom(上記参照)。

mark

Arranges for fast-import to save a reference to the current object, allowing the frontend to recall this object at a future point in time, without knowing its SHA-1. Here the current object is the object creation command the mark command appears within. This can be commit, tag, and blob, but commit is the most common usage.現在のオブジェクトへの参照を保存するための高速インポートを手配し、フロントエンドが将来のある時点でそのオブジェクトのSHA-1を知らなくてもこのオブジェクトを呼び出せるようにします。ここで、現在のオブジェクトは、コマンドが含まれているオブジェクト作成コマンドmarkです。これは、することができcommittagblob、しかし、commit最も一般的な使用方法です。

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

New marks are created automatically. Existing marks can be moved to another object simply by reusing the same <idnum> in another mark command.新しいマークが自動的に作成されます。既存のマークは<idnum>、他のmarkコマンドで同じマークを再利用することで、他のオブジェクトに移動できます。

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元のソース管理システム内のオブジェクトの名前を提供します。fast-importは単にこのディレクティブを無視しますが、fast-importにフィードする前にストリームを操作してストリームを変更するフィルタプロセスはこの情報を使用するかもしれません。

	'original-oid' SP <object-identifier> LF

where <object-identifer> is any string not containing LF.ここ<object-identifer>で、LFを含まない任意の文字列です。

tag

Creates an annotated tag referring to a specific commit. To create lightweight (non-annotated) tags see the reset command below.特定のコミットを参照する注釈付きタグを作成します。軽量(注釈なし)タグを作成するには、reset以下のコマンドを参照してください。

	'tag' SP <name> LF
	'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.どこ<name>作成するタグの名前です。

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.タグ名はrefs/tags/Gitに格納されるとき自動的に前に置かれます、それでCVSブランチシンボルRELENG-1_0-FINALをインポートすることはただのRELENG-1_0-FINALため<name>に使い、速いインポートは対応するrefを書くでしょう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.の値は<name>Gitでは有効なrefname でなければならず、したがってスラッシュを含めることができます。LFGitのもしrefnameでは有効ではありません、何の引用またはエスケープ構文は、ここでサポートされていません。

The from command is the same as in the commit command; see above for details.fromコマンドはと同じであるcommitコマンド。詳細は上記を参照してください。

The tagger command uses the same format as committer within commit; again see above for details.taggerコマンドと同じフォーマットを使用committercommit、再度詳細については上記を見てください。

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.data以下のコマンドtaggerは注釈付きタグメッセージを供給しなければなりません(dataコマンド構文については下記参照)。空のタグメッセージをインポートするには、長さ0のデータを使用します。タグメッセージは自由形式であり、Gitによって解釈されません。高速インポートでは他のエンコーディングの指定が許可されていないため、現在はUTF-8でエンコードする必要があります。

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

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コマンドを使用すると、フロントエンドfromは既存のブランチに対して新しいコマンドを発行したり、新しいコミットを作成せずに既存のコミットから新しいブランチを作成したりできます。

	'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.詳細については<ref>、および<commit-ish>上記参照下commitfrom

The LF after the command is optional (it used to be required).LFコマンドの後はオプションです(以前は必須でした)。

The reset command can also be used to create lightweight (non-annotated) tags. For example:このresetコマンドを使用して、軽量(注釈なし)タグを作成することもできます。例えば:

reset refs/tags/938
from :938

would create the lightweight tag refs/tags/938 referring to whatever commit mark :938 references.refs/tags/938コミットマークが:938参照するものは何でも参照する軽量のタグを作成します。

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.1つのファイルリビジョンをpackfileに書き込むことを要求します。改訂はいかなるコミットにも関連しません。この接続はcommit、割り当てられたマークを通してBLOBを参照することによって、後続のコマンドで形成される必要があります。

	'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.一部のフロントエンドは独自にBLOB用のGit SHA-1を生成し、それを直接フィードすることを選択したため、markコマンドはここではオプションですcommit。マークは保存するのが安価で使いやすいので、これは通常それが価値があるより多くの仕事です。

data

Supplies raw data (for use as blob/file content, commit messages, or annotated tag messages) to fast-import. Data can be supplied using an exact byte count or delimited with a terminating line. Real frontends intended for production-quality conversions should always use the exact byte count format, as it is more robust and performs better. The delimited format is intended primarily for testing fast-import.生データ(BLOB /ファイルコンテンツ、コミットメッセージ、または注釈付きタグメッセージとして使用)を高速インポートに提供します。データは、正確なバイト数を使用して指定することも、終了行で区切ることもできます。プロダクション品質の変換を目的とした実際のフロントエンドは、より正確でパフォーマンスが高いため、常に正確なバイトカウント形式を使用する必要があります。区切り形式は、主に高速インポートのテスト用です。

Comment lines appearing within the <raw> part of data commands are always taken to be part of the body of the data and are therefore never ignored by fast-import. This makes it safe to import any file/message content whose lines might start with #.コマンドの<raw>一部の中にあるコメント行dataは、常にデータの本体の一部として扱われるため、高速インポートによって無視されることはありません。これにより、行が先頭にくる可能性のあるファイル/メッセージの内容をインポートしても安全になります#

Exact byte count format 正確なバイトカウントフォーマット

The frontend must specify the number of bytes of data.フロントエンドはデータのバイト数を指定しなければなりません。

	'data' SP <count> LF
	<raw> LF?

where <count> is the exact number of bytes appearing within <raw>. The value of <count> is expressed as an ASCII decimal integer. The LF on either side of <raw> is not included in <count> and will not be included in the imported data.ここに<count>は正確なバイト数が含まれています<raw>。の値は<count>、ASCII 10進整数として表されます。LFいずれかの側<raw>に含まれない<count>とは、インポートされたデータに含まれないであろう。

The LF after <raw> is optional (it used to be required) but recommended. Always including it makes debugging a fast-import stream easier as the next command always starts in column 0 of the next line, even if <raw> did not end with an LF.LF後は、<raw>(それが要求されるために使用される)が、推奨オプションです。次のコマンドは常に。で<raw>終わらなくても、次のコマンドが常に次の行の列0から始まるので、それを常に含めることは速いインポートストリームのデバッグをより簡単にしますLF

Delimited format 区切り形式

A delimiter string is used to mark the end of the data. fast-import will compute the length by searching for the delimiter. This format is primarily useful for testing and is not recommended for real data.区切り文字列はデータの終わりを示すために使用されます。fast-importは区切り文字を探すことによって長さを計算します。このフォーマットは主にテストに役立ち、実際のデータにはお勧めできません。

	'data' SP '<<' <delim> LF
	<raw> LF
	<delim> LF
	LF?

where <delim> is the chosen delimiter string. The string <delim> must not appear on a line by itself within <raw>, as otherwise fast-import will think the data ends earlier than it really does. The LF immediately trailing <raw> is part of <raw>. This is one of the limitations of the delimited format, it is impossible to supply a data chunk which does not have an LF as its last byte.ここ<delim>で、は選択された区切り文字列です。そうでなければfast-importはデータが実際より早く終了すると考えるので、文字列<delim>はその中<raw>に単独で行に現れてはいけません。LFすぐに後続<raw>の一部です<raw>。これは区切り形式の制限の1つです。最後のバイトとしてLFを持たないデータチャンクを提供することは不可能です。

The LF after <delim> LF is optional (it used to be required).LF後には、<delim> LF(それが必要とされるために使用される)は任意です。

checkpoint

Forces fast-import to close the current packfile, start a new one, and to save out all current branch refs, tags and marks.高速インポートで現在のパックファイルを閉じ、新しいパックファイルを開始し、現在のブランチの参照、タグ、およびマークをすべて保存します。

	'checkpoint' LF
	LF?

Note that fast-import automatically switches packfiles when the current packfile reaches --max-pack-size, or 4 GiB, whichever limit is smaller. During an automatic packfile switch fast-import does not update the branch refs, tags or marks.現在のパックファイルが--max-pack-size、つまり4 GiBのいずれか小さい方の制限に達すると、fast-importは自動的にパックファイルを切り替えます。自動パックファイルの切り替え中、fast-importはブランチの参照、タグ、マークを更新しません。

As a checkpoint can require a significant amount of CPU time and disk IO (to compute the overall pack SHA-1 checksum, generate the corresponding index file, and update the refs) it can easily take several minutes for a single checkpoint command to complete.checkpointCPU時間とディスクIO、かなりの量を必要とすることができ、それは簡単に、単一のに数分かかることができます(全体パックSHA-1チェックサムを計算し、対応するインデックスファイルを生成し、そしてレフリーを更新するために)checkpoint完了するためのコマンド。

Frontends may choose to issue checkpoints during extremely large and long running imports, or when they need to allow another Git process access to a branch. However given that a 30 GiB Subversion repository can be loaded into Git through fast-import in about 3 hours, explicit checkpointing may not be necessary.フロントエンドは、非常に大規模で長期にわたるインポート中、または別のGitプロセスがブランチへのアクセスを許可する必要があるときに、チェックポイントを発行することを選択することがあります。ただし、30 GiBのSubversionリポジトリを約3時間で高速インポートでGitにロードできることを考えると、明示的なチェックポイント設定は必要ないかもしれません。

The LF after the command is optional (it used to be required).LFコマンドの後はオプションです(以前は必須でした)。

progress

Causes fast-import to print the entire progress line unmodified to its standard output channel (file descriptor 1) when the command is processed from the input stream. The command otherwise has no impact on the current import, or on any of fast-import’s internal state.progressコマンドが入力ストリームから処理されるときに、高速インポートがその行全体をその標準出力チャネル(ファイル記述子1)に変更されずに印刷するようにします。それ以外の場合、このコマンドは現在のインポート、または高速インポートの内部状態には影響しません。

	'progress' SP <any> LF
	LF?

The <any> part of the command may contain any sequence of bytes that does not contain LF. The LF after the command is optional. Callers may wish to process the output through a tool such as sed to remove the leading part of the line, for example:<any>コマンドの一部には、含まれていないバイトのシーケンスを含めることができますLFLFコマンドの後はオプションです。呼び出し側はsedのようなツールを通して出力を処理して行の先頭部分を削除したいかもしれません。例えば:

frontend | git fast-import | sed 's/^progress //'

Placing a progress command immediately after a checkpoint will inform the reader when the checkpoint has been completed and it can safely access the refs that fast-import updated.aのprogress直後にコマンドを入力するcheckpointと、checkpoint完了したことが読者に通知され、fast-importが更新した参照に安全にアクセスできます。

get-mark

Causes fast-import to print the SHA-1 corresponding to a mark to stdout or to the file descriptor previously arranged with the --cat-blob-fd argument. The command otherwise has no impact on the current import; its purpose is to retrieve SHA-1s that later commits might want to refer to in their commit messages.高速インポートで、マークに対応するSHA-1を標準出力に出力するか、または--cat-blob-fd引数を使用して以前に配置されたファイル記述子に出力します。それ以外のコマンドは、現在のインポートには影響しません。その目的は、後でコミットがコミットメッセージで参照したいと思うかもしれないSHA-1を検索することです。

	'get-mark' SP ':' <idnum> LF

This command can be used anywhere in the stream that comments are accepted. In particular, the get-mark command can be used in the middle of a commit but not in the middle of a data command.このコマンドは、コメントが受け入れられるストリーム内のどこでも使用できます。特に、get-markコマンドはコミットの途中で使用できますが、コマンドの途中では使用できませんdata

See “Responses To Commands” below for details about how to read this output safely.この出力を安全に読み取る方法の詳細については、後述の「コマンドに対する応答」を参照してください。

cat-blob

Causes fast-import to print a blob to a file descriptor previously arranged with the --cat-blob-fd argument. The command otherwise has no impact on the current import; its main purpose is to retrieve blobs that may be in fast-import’s memory but not accessible from the target repository.fast-importに、--cat-blob-fd引数で前に配置されたファイル記述子にBLOBを印刷させます。それ以外のコマンドは、現在のインポートには影響しません。その主な目的は、高速インポートのメモリにはあるがターゲットリポジトリからはアクセスできないBLOBを取得することです。

	'cat-blob' SP <dataref> LF

The <dataref> can be either a mark reference (:<idnum>) set previously or a full 40-byte SHA-1 of a Git blob, preexisting or ready to be written.これ<dataref>は、:<idnum>以前に設定されたmark reference()またはGit Blobの完全な40バイトのSHA-1のいずれかで、既存のものでも書き込み可能なものでもかまいません。

Output uses the same format as git cat-file --batch:出力は以下と同じフォーマットを使用しますgit cat-file --batch

<sha1> SP 'blob' SP <size> LF
<contents> LF

This command can be used anywhere in the stream that comments are accepted. In particular, the cat-blob command can be used in the middle of a commit but not in the middle of a data command.このコマンドは、コメントが受け入れられるストリーム内のどこでも使用できます。特に、cat-blobコマンドはコミットの途中で使用できますが、コマンドの途中では使用できませんdata

See “Responses To Commands” below for details about how to read this output safely.この出力を安全に読み取る方法の詳細については、後述の「コマンドに対する応答」を参照してください。

ls

Prints information about the object at a path to a file descriptor previously arranged with the --cat-blob-fd argument. This allows printing a blob from the active commit (with cat-blob) or copying a blob or tree from a previous commit for use in the current one (with filemodify).オブジェクト--cat-blob-fd引数に関する前に配置されたファイル記述子へのパスにあるオブジェクトに関する情報を印刷します。これにより、アクティブなコミットからのBLOBの印刷(with cat-blob)、または現在のコミットでの使用のための以前のコミットからのBLOBまたはツリーのコピー(with filemodify)が可能になります。

The ls command can be used anywhere in the stream that comments are accepted, including the middle of a commit.このlsコマンドは、コミットの途中を含め、コメントが受け入れられるストリーム内の任意の場所で使用できます。

Reading from the active commit アクティブなコミットから読む

This form can only be used in the middle of a commit. The path names a directory entry within fast-import’s active commit. The path must be quoted in this case.このフォームはaの途中でしか使えませんcommit。このパスは、高速インポートのアクティブコミット内のディレクトリエントリを指定します。この場合、パスは引用符で囲む必要があります。

	'ls' SP <path> LF
Reading from a named tree 名前付きツリーから読む

The <dataref> can be a mark reference (:<idnum>) or the full 40-byte SHA-1 of a Git tag, commit, or tree object, preexisting or waiting to be written. The path is relative to the top level of the tree named by <dataref>.これ<dataref>は、マーク参照(:<idnum>)、または既存の、または書き込まれるのを待っているGitタグ、コミット、またはツリーオブジェクトの完全な40バイトのSHA-1です。パスは、という名前のツリーの最上位レベルからの相対パスです<dataref>

	'ls' SP <dataref> SP <path> LF

See filemodify above for a detailed description of <path>.の詳細についてはfilemodify上記を参照してください<path>

Output uses the same format as git ls-tree <tree> -- <path>:出力は以下と同じフォーマットを使用しますgit ls-tree <tree> -- <path>

<mode> SP ('blob' | 'tree' | 'commit') SP <dataref> HT <path> LF

The <dataref> represents the blob, tree, or commit object at <path> and can be used in later get-mark, cat-blob, filemodify, or ls commands.<dataref>は、<path>にあるBLOB、ツリー、またはコミットオブジェクトを表し、後のget-markcat-blobfilemodify、またはlsコマンドで使用できます。

If there is no file or subtree at that path, git fast-import will instead reportそのパスにファイルまたはサブツリーがない場合は、代わりにgit fast-importは報告します。

missing SP <path> LF

See “Responses To Commands” below for details about how to read this output safely.この出力を安全に読み取る方法の詳細については、後述の「コマンドに対する応答」を参照してください。

feature

Require that fast-import supports the specified feature, or abort if it does not.高速インポートが指定された機能をサポートすることを要求するか、サポートしない場合は中止します。

	'feature' SP <feature> ('=' <argument>)? LF

The <feature> part of the command may be any one of the following:コマンドの<feature>部分は、次のいずれかになります。

date-format 日付フォーマット
export-marks 輸出マーク
relative-marks 相対マーク
no-relative-marks 相対マークなし
force

Act as though the corresponding command-line option with a leading -- was passed on the command line (see OPTIONS, above).先行する対応するコマンドラインオプションが--コマンドラインで渡されたかのように振る舞います(上記のオプションを参照)。

import-marks 輸入マーク
import-marks-if-exists

Like --import-marks except in two respects: first, only one "feature import-marks" or "feature import-marks-if-exists" command is allowed per stream; second, an --import-marks= or --import-marks-if-exists command-line option overrides any of these "feature" commands in the stream; third, "feature import-marks-if-exists" like a corresponding command-line option silently skips a nonexistent file.2つの点を除いて--import-marksと同じです。まず、ストリームごとに1つの "feature import-marks"または "feature import-marks-if-exists"コマンドのみが許可されます。次に、--import-marks =または--import-marks-if-existsコマンドラインオプションは、ストリーム内のこれらの「機能」コマンドをオーバーライドします。3番目に、対応するコマンドラインオプションのような "feature import-marks-if-exists"は存在しないファイルを静かにスキップします。

get-mark ゲットマーク
cat-blob 猫ブロブ
ls

Require that the backend support the get-mark, cat-blob, or ls command respectively. Versions of fast-import not supporting the specified command will exit with a message indicating so. This lets the import error out early with a clear message, rather than wasting time on the early part of an import before the unsupported command is detected.バックエンドがそれぞれget-markcat-blob、またはlsコマンドをサポートすることを要求します。指定されたコマンドをサポートしていないバージョンのfast-importは、その旨を示すメッセージを出して終了します。これにより、サポートされていないコマンドが検出される前にインポートの早い段階で時間を無駄にするのではなく、明確なメッセージを表示してインポートエラーを早期に解決できます。

notes ノート

Require that the backend support the notemodify (N) subcommand to the commit command. Versions of fast-import not supporting notes will exit with a message indicating so.バックエンドがcommitコマンドに対するnotemodify(N)サブコマンドをサポートすることを要求します。ノートをサポートしていないバージョンのfast-importはそうを示すメッセージで終了します。

done 終わった

Error out if the stream ends without a done command. Without this feature, errors causing the frontend to end abruptly at a convenient point in the stream can go undetected. This may occur, for example, if an import front end dies in mid-operation without emitting SIGTERM or SIGKILL at its subordinate git fast-import instance.ストリームがdoneコマンドなしで終了した場合はエラーになります。この機能がなければ、フロントエンドをストリームの都合の良い時点で突然終了させるエラーが検出されない可能性があります。これは、例えば、インポートフロントエンドが、その下位のgit fast-importインスタンスでSIGTERMまたはSIGKILLを発行せずに操作中に死んだ場合に起こります。

option

Processes the specified option so that git fast-import behaves in a way that suits the frontend’s needs. Note that options specified by the frontend are overridden by any options the user may specify to git fast-import itself.指定されたオプションを処理して、git fast-importがフロントエンドのニーズに合った方法で動作するようにします。フロントエンドで指定されたオプションは、ユーザ自身が高速インポート自身をgitするように指定したオプションによって上書きされることに注意してください。

    'option' SP <option> LF

The <option> part of the command may contain any of the options listed in the OPTIONS section that do not change import semantics, without the leading -- and is treated in the same way.<option>コマンドの一部には、OPTIONSセクションにリストされているオプションのうち、インポートの意味を変更しないものが含まれている場合があります--

Option commands must be the first commands on the input (not counting feature commands), to give an option command after any non-option command is an error.オプションコマンド以外のコマンドがエラーになった後にオプションコマンドを指定するには、オプションコマンドを入力の最初のコマンドにする必要があります(機能コマンドは数えません)。

The following command-line options change import semantics and may therefore not be passed as option:次のコマンドラインオプションはインポートのセマンティクスを変更するため、オプションとして渡すことはできません。

  • date-format日付フォーマット

  • import-marks輸入マーク

  • export-marks輸出マーク

  • cat-blob-fd

  • force

done

If the done feature is not in use, treated as if EOF was read. This can be used to tell fast-import to finish early.場合done機能を使用していないEOFが読まれたかのように、処理されました。これはfast-importに早く終了するように指示するために使うことができます。

If the --done command-line option or feature done command is in use, the done command is mandatory and marks the end of the stream.場合は--done、コマンドラインオプションまたはfeature doneコマンドが使用されている、doneコマンドは必須であり、ストリームの終わりをマークします。

RESPONSES TO COMMANDSコマンドに対する応答

New objects written by fast-import are not available immediately. Most fast-import commands have no visible effect until the next checkpoint (or completion). The frontend can send commands to fill fast-import’s input pipe without worrying about how quickly they will take effect, which improves performance by simplifying scheduling.高速インポートによって作成された新しいオブジェクトはすぐには利用できません。ほとんどの高速インポートコマンドは、次のチェックポイント(または完了)まで目に見える影響を与えません。フロントエンドは、どれほど早く効果が出るのかを気にせずにfast-importの入力パイプを埋めるコマンドを送ることができます。これはスケジューリングを単純化することによってパフォーマンスを向上させます。

For some frontends, though, it is useful to be able to read back data from the current repository as it is being updated (for example when the source material describes objects in terms of patches to be applied to previously imported objects). This can be accomplished by connecting the frontend and fast-import via bidirectional pipes:ただし、フロントエンドによっては、更新中の現在のリポジトリからデータを読み返すことができると便利です(たとえば、ソースマテリアルに、以前にインポートしたオブジェクトに適用するパッチに関してオブジェクトが記述されている場合など)。これは、フロントエンドと高速インポートを双方向パイプで接続することで実現できます。

mkfifo fast-import-output
frontend <fast-import-output |
git fast-import >fast-import-output

A frontend set up this way can use progress, get-mark, ls, and cat-blob commands to read information from the import in progress.フロントエンドは使用することができ、このように設定しprogressget-markls、およびcat-blob進行中のインポートから情報を読み取るためのコマンド。

To avoid deadlock, such frontends must completely consume any pending output from progress, ls, get-mark, and cat-blob before performing writes to fast-import that might block.デッドロックを回避するために、そのようなフロントエンドが完全に保留中の出力を消費しなければならないprogresslsget-mark、およびcat-blob実行する前に、高速インポートするブロックされる可能性があります書き込みます。

CRASH REPORTSクラッシュレポート

If fast-import is supplied invalid input it will terminate with a non-zero exit status and create a crash report in the top level of the Git repository it was importing into. Crash reports contain a snapshot of the internal fast-import state as well as the most recent commands that lead up to the crash.fast-importに無効な入力が与えられた場合、それは0以外の終了ステータスで終了し、インポートしていたGitリポジトリのトップレベルにクラッシュレポートを作成します。クラッシュレポートには、内部の高速インポート状態のスナップショットとクラッシュの原因となった最新のコマンドが含まれています。

All recent commands (including stream comments, file changes and progress commands) are shown in the command history within the crash report, but raw file data and commit messages are excluded from the crash report. This exclusion saves space within the report file and reduces the amount of buffering that fast-import must perform during execution.最近のすべてのコマンド(ストリームコメント、ファイル変更、進行コマンドを含む)はクラッシュレポート内のコマンド履歴に表示されますが、生のファイルデータとコミットメッセージはクラッシュレポートから除外されます。この除外によってレポートファイル内のスペースが節約され、高速インポートが実行中に実行しなければならないバッファリングの量が減少します。

After writing a crash report fast-import will close the current packfile and export the marks table. This allows the frontend developer to inspect the repository state and resume the import from the point where it crashed. The modified branches and tags are not updated during a crash, as the import did not complete successfully. Branch and tag information can be found in the crash report and must be applied manually if the update is needed.クラッシュレポートを書いた後、fast-importは現在のpackfileを閉じてmarkテーブルをエクスポートします。これによりフロントエンドの開発者はリポジトリの状態を調べてクラッシュしたところからインポートを再開することができます。インポートが正常に完了しなかったため、変更されたブランチとタグはクラッシュ時に更新されません。ブランチとタグの情報はクラッシュレポートにあります。更新が必要な場合は手動で適用する必要があります。

An example crash:クラッシュの例:

$ cat >in <<END_OF_INPUT
# my very first test commit
commit refs/heads/master
committer Shawn O. Pearce <spearce> 19283 -0400
# who is that guy anyway?
data <<EOF
this is my commit
EOF
M 644 inline .gitignore
data <<EOF
.gitignore
EOF
M 777 inline bob
END_OF_INPUT
$ git fast-import <in
fatal: Corrupt mode: M 777 inline bob
fast-import: dumping crash report to .git/fast_import_crash_8434
$ cat .git/fast_import_crash_8434
fast-import crash report:
    fast-import process: 8434
    parent process     : 1391
    at Sat Sep 1 00:58:12 2007
fatal: Corrupt mode: M 777 inline bob
Most Recent Commands Before Crash
---------------------------------
  # my very first test commit
  commit refs/heads/master
  committer Shawn O. Pearce <spearce> 19283 -0400
  # who is that guy anyway?
  data <<EOF
  M 644 inline .gitignore
  data <<EOF
* M 777 inline bob
Active Branch LRU
-----------------
    active_branches = 1 cur, 5 max
pos  clock name
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 1)      0 refs/heads/master
Inactive Branches
-----------------
refs/heads/master:
  status      : active loaded dirty
  tip commit  : 0000000000000000000000000000000000000000
  old tree    : 0000000000000000000000000000000000000000
  cur tree    : 0000000000000000000000000000000000000000
  commit clock: 0
  last pack   :
-------------------
END OF CRASH REPORT

TIPS AND TRICKSヒントとコツ

The following tips and tricks have been collected from various users of fast-import, and are offered here as suggestions.以下のヒントやコツは、高速インポートのさまざまなユーザーから集められたもので、ここで提案として提供されています。

Use One Mark Per Commitコミットごとに1つのマークを使用

When doing a repository conversion, use a unique mark per commit (mark :<n>) and supply the --export-marks option on the command line. fast-import will dump a file which lists every mark and the Git object SHA-1 that corresponds to it. If the frontend can tie the marks back to the source repository, it is easy to verify the accuracy and completeness of the import by comparing each Git commit to the corresponding source revision.リポジトリ変換を行うときは、commit(mark :<n>)ごとに固有のマークを使用し、コマンドラインで--export-marksオプションを指定してください。fast-importはすべてのマークとそれに対応するGitオブジェクトSHA-1をリストしたファイルをダンプします。フロントエンドがマークをソースリポジトリに結び付けることができる場合、Gitの各コミットを対応するソースリビジョンと比較することでインポートの正確性と完全性を簡単に確認できます。

Coming from a system such as Perforce or Subversion this should be quite simple, as the fast-import mark can also be the Perforce changeset number or the Subversion revision number.高速インポートマークはPerforceチェンジセット番号またはSubversionリビジョン番号である可能性があるため、PerforceやSubversionなどのシステムから来る場合、これは非常に単純なはずです。

Freely Skip Around Branches枝を自由にスキップ

Don’t bother trying to optimize the frontend to stick to one branch at a time during an import. Although doing so might be slightly faster for fast-import, it tends to increase the complexity of the frontend code considerably.インポート中に一度に1つのブランチに固執するようにフロントエンドを最適化しようとしても気にしないでください。そうすることは速いインポートのためにわずかに速いかもしれませんが、それはフロントエンドコードの複雑さをかなり増加させる傾向があります。

The branch LRU builtin to fast-import tends to behave very well, and the cost of activating an inactive branch is so low that bouncing around between branches has virtually no impact on import performance.高速インポートに組み込まれているブランチLRUは非常にうまく動作する傾向があり、非アクティブブランチをアクティブにするためのコストが非常に低いため、ブランチ間を行き来してもインポートパフォーマンスにはほとんど影響がありません。

Handling Renamesリネームの処理

When importing a renamed file or directory, simply delete the old name(s) and modify the new name(s) during the corresponding commit. Git performs rename detection after-the-fact, rather than explicitly during a commit.名前を変更したファイルまたはディレクトリをインポートするときは、対応するコミット中に古い名前を削除し、新しい名前を変更するだけです。Gitは、コミット中に明示的にではなく、事後に名前の変更の検出を行います。

Use Tag Fixup Branchesタグ修正ブランチを使用する

Some other SCM systems let the user create a tag from multiple files which are not from the same commit/changeset. Or to create tags which are a subset of the files available in the repository.他のSCMシステムの中には、同じコミット/チェンジセットからではない複数のファイルからユーザーにタグを作成させるものがあります。リポジトリで利用可能なファイルのサブセットであるタグを作成することもできます。

Importing these tags as-is in Git is impossible without making at least one commit which “fixes up” the files to match the content of the tag. Use fast-import’s reset command to reset a dummy branch outside of your normal branch space to the base commit for the tag, then commit one or more file fixup commits, and finally tag the dummy branch.これらのタグをGitでそのままインポートすることは、タグの内容に一致するようにファイルを「修正」するコミットを少なくとも1つ作成しなければ不可能です。fast-importのresetコマンドを使用して、通常のブランチスペースの外側にあるダミーブランチをタグのベースコミットにリセットしてから、1つ以上のファイル修正コミットをコミットし、最後にダミーブランチにタグを付けます。

For example since all normal branches are stored under refs/heads/ name the tag fixup branch TAG_FIXUP. This way it is impossible for the fixup branch used by the importer to have namespace conflicts with real branches imported from the source (the name TAG_FIXUP is not refs/heads/TAG_FIXUP).たとえば、すべての通常のブランチはrefs/heads/tag fixupブランチという名前で保存されていTAG_FIXUPます。このように、インポーターによって使用されるfixupブランチが、ソースからインポートされた実際のブランチと名前空間の競合を持つことは不可能です(名前TAG_FIXUPはそうではありませんrefs/heads/TAG_FIXUP)。

When committing fixups, consider using merge to connect the commit(s) which are supplying file revisions to the fixup branch. Doing so will allow tools such as git blame to track through the real commit history and properly annotate the source files.merge修正をコミットするときは、ファイルリビジョンを提供しているコミットを修正ブランチに接続することを検討してください。そうすることで、git blameなどのツールが実際のコミット履歴を追跡し、ソースファイルに適切に注釈を付けることができます。

After fast-import terminates the frontend will need to do rm .git/TAG_FIXUP to remove the dummy branch.高速インポートが終了した後、フロントエンドはrm .git/TAG_FIXUPダミーブランチを削除する必要があります。

Import Now, Repack Later今すぐインポートし、後で再梱包

As soon as fast-import completes the Git repository is completely valid and ready for use. Typically this takes only a very short time, even for considerably large projects (100,000+ commits).高速インポートが完了するとすぐに、Gitリポジトリは完全に有効になり使用できるようになります。通常、これはかなり大きなプロジェクト(100,000以上のコミット)の場合でも非常に短時間で完了します。

However repacking the repository is necessary to improve data locality and access performance. It can also take hours on extremely large projects (especially if -f and a large --window parameter is used). Since repacking is safe to run alongside readers and writers, run the repack in the background and let it finish when it finishes. There is no reason to wait to explore your new Git project!ただし、データの局所性とアクセスパフォーマンスを向上させるには、リポジトリを再パックする必要があります。非常に大きなプロジェクトでも時間がかかることがあります(特に-fと大きな--windowパラメータが使用されている場合)。再梱包は、読者や作家と一緒に実行しても安全なので、バックグラウンドで再梱包を実行して、終了したら終了させます。新しいGitプロジェクトを探索するのを待つ理由はありません。

If you choose to wait for the repack, don’t try to run benchmarks or performance tests until repacking is completed. fast-import outputs suboptimal packfiles that are simply never seen in real use situations.再梱包を待つことを選択した場合は、再梱包が完了するまでベンチマークまたはパフォーマンステストを実行しないでください。fast-importは、実際の使用状況では決して見られないような最適以下のパックファイルを出力します。

Repacking Historical Data履歴データの再梱包

If you are repacking very old imported data (e.g. older than the last year), consider expending some extra CPU time and supplying --window=50 (or higher) when you run git repack. This will take longer, but will also produce a smaller packfile. You only need to expend the effort once, and everyone using your project will benefit from the smaller repository.非常に古いインポートデータ(昨年より古いなど)を再パックする場合は、git repackを実行するときに、余分なCPU時間を費やして--window = 50(またはそれ以上)を指定することを検討してください。これにはもっと時間がかかりますが、より小さなパックファイルも作成されます。あなたは一度だけ努力を費やす必要がある、そしてあなたのプロジェクトを使う誰もがより小さなリポジトリから利益を得るでしょう。

Include Some Progress Messagesいくつかの進捗メッセージを含める

Every once in a while have your frontend emit a progress message to fast-import. The contents of the messages are entirely free-form, so one suggestion would be to output the current month and year each time the current commit date moves into the next month. Your users will feel better knowing how much of the data stream has been processed.時々あなたのフロントエンドprogressはfast-importにメッセージを出してもらう。メッセージの内容は完全に自由形式であるため、現在のコミット日が翌月に移動するたびに現在の月と年を出力することをお勧めします。ユーザーは、データストリームのうちどれだけが処理されたかを知っているほうがよいでしょう。

PACKFILE OPTIMIZATIONパックファイルの最適化

When packing a blob fast-import always attempts to deltify against the last blob written. Unless specifically arranged for by the frontend, this will probably not be a prior version of the same file, so the generated delta will not be the smallest possible. The resulting packfile will be compressed, but will not be optimal.BLOBをパッキングするとき、高速インポートは常に最後に書き込まれたBLOBに対して緻密化しようとします。フロントエンドによって特別に手配されていない限り、これはおそらく同じファイルの前のバージョンではないので、生成されたデルタは可能な限り最小にはなりません。結果のパックファイルは圧縮されますが、最適ではありません。

Frontends which have efficient access to all revisions of a single file (for example reading an RCS/CVS ,v file) can choose to supply all revisions of that file as a sequence of consecutive blob commands. This allows fast-import to deltify the different file revisions against each other, saving space in the final packfile. Marks can be used to later identify individual file revisions during a sequence of commit commands.単一ファイルのすべてのリビジョンに効率的にアクセスできるフロントエンド(たとえば、RCS / CVS、vファイルの読み取り)は、そのファイルのすべてのリビジョンを連続したblobコマンドのシーケンスとして提供することを選択できます。これにより、高速インポートで異なるファイルのリビジョンを互いに区別し、最終パックファイルのスペースを節約できます。マークは、一連のcommitコマンド中に個々のファイルリビジョンを後で識別するために使用できます。

The packfile(s) created by fast-import do not encourage good disk access patterns. This is caused by fast-import writing the data in the order it is received on standard input, while Git typically organizes data within packfiles to make the most recent (current tip) data appear before historical data. Git also clusters commits together, speeding up revision traversal through better cache locality.高速インポートによって作成されたpackfileは、良いディスクアクセスパターンを推奨しません。これは、標準入力で受信した順序でデータを高速インポートで書き込むのに対し、Gitは通常、最新(現在のチップ)のデータを履歴データの前に表示するためにデータをパックファイル内に編成するためです。Gitはコミットをまとめてクラスタ化し、キャッシュの局所性を向上させることでリビジョントラバーサルをスピードアップします。

For this reason it is strongly recommended that users repack the repository with git repack -a -d after fast-import completes, allowing Git to reorganize the packfiles for faster data access. If blob deltas are suboptimal (see above) then also adding the -f option to force recomputation of all deltas can significantly reduce the final packfile size (30-50% smaller can be quite typical).このためgit repack -a -d、高速インポートの完了後にユーザーがリポジトリを再パックすることを強くお勧めします。これにより、Gitはデータアクセスを高速化するためにパックファイルを再編成できます。ブロブのデルタが最適とは-f言えない場合(上記参照)、すべてのデルタを強制的に再計算するオプションを追加すると、最終的なパックファイルのサイズを大幅に減らすことができます(30〜50%小さいのが一般的です)。

MEMORY UTILIZATIONメモリの利用

There are a number of factors which affect how much memory fast-import requires to perform an import. Like critical sections of core Git, fast-import uses its own memory allocators to amortize any overheads associated with malloc. In practice fast-import tends to amortize any malloc overheads to 0, due to its use of large block allocations.高速インポートでインポートを実行するために必要なメモリ量に影響を与える要因がいくつかあります。コアGitの重要なセクションと同様に、fast-importはmallocに関連したオーバーヘッドを償うためにそれ自身のメモリアロケータを使います。実際には、高速インポートは、大きなブロック割り当てを使用するため、mallocオーバーヘッドを0に償却する傾向があります。

per objectオブジェクトごと

fast-import maintains an in-memory structure for every object written in this execution. On a 32 bit system the structure is 32 bytes, on a 64 bit system the structure is 40 bytes (due to the larger pointer sizes). Objects in the table are not deallocated until fast-import terminates. Importing 2 million objects on a 32 bit system will require approximately 64 MiB of memory.fast-importは、この実行で書かれたすべてのオブジェクトに対してメモリ内構造を維持します。32ビットシステムでは構造体は32バイト、64ビットシステムでは構造体は40バイトです(ポインタサイズが大きいため)。テーブル内のオブジェクトは、高速インポートが終了するまで割り当て解除されません。32ビットシステムに200万個のオブジェクトをインポートするには、約64 MiBのメモリが必要です。

The object table is actually a hashtable keyed on the object name (the unique SHA-1). This storage configuration allows fast-import to reuse an existing or already written object and avoid writing duplicates to the output packfile. Duplicate blobs are surprisingly common in an import, typically due to branch merges in the source.オブジェクトテーブルは、実際にはオブジェクト名をキーとするハッシュテーブルです(一意のSHA-1)。このストレージ構成により、高速インポートで既存またはすでに書き込まれているオブジェクトを再利用し、出力パックファイルに重複して書き込まれることを回避できます。重複したBLOBは、インポートでは驚くほど一般的です。通常、ソース内のブランチのマージが原因です。

per mark1マークあたり

Marks are stored in a sparse array, using 1 pointer (4 bytes or 8 bytes, depending on pointer size) per mark. Although the array is sparse, frontends are still strongly encouraged to use marks between 1 and n, where n is the total number of marks required for this import.マークは、マークごとに1つのポインタ(ポインタサイズに応じて4バイトまたは8バイト)を使用してスパース配列に格納されます。配列はスパースですが、フロントエンドでは1からnまでのマークを使用することを強くお勧めします。nはこのインポートに必要なマークの総数です。

per branch枝ごと

Branches are classified as active and inactive. The memory usage of the two classes is significantly different.分岐はアクティブと非アクティブに分類されます。2つのクラスのメモリ使用量は大きく異なります。

Inactive branches are stored in a structure which uses 96 or 120 bytes (32 bit or 64 bit systems, respectively), plus the length of the branch name (typically under 200 bytes), per branch. fast-import will easily handle as many as 10,000 inactive branches in under 2 MiB of memory.非アクティブなブランチは、ブランチごとに96または120バイト(それぞれ32ビットまたは64ビットシステム)とブランチ名の長さ(通常は200バイト未満)を使用する構造体に格納されます。高速インポートでは、2 MiB未満のメモリで10,000個もの非アクティブブランチを簡単に処理できます。

Active branches have the same overhead as inactive branches, but also contain copies of every tree that has been recently modified on that branch. If subtree include has not been modified since the branch became active, its contents will not be loaded into memory, but if subtree src has been modified by a commit since the branch became active, then its contents will be loaded in memory.アクティブブランチは、非アクティブブランチと同じオーバーヘッドを持ちますが、そのブランチで最近変更されたすべてのツリーのコピーも含みます。includeブランチがアクティブになってからサブツリーが変更されていない場合、その内容はメモリにロードされませんがsrc、ブランチがアクティブになってからサブツリーがコミットによって変更されている場合は、その内容がメモリにロードされます。

As active branches store metadata about the files contained on that branch, their in-memory storage size can grow to a considerable size (see below).アクティブブランチがそのブランチに含まれるファイルに関するメタデータを格納すると、それらのメモリ内ストレージサイズはかなりのサイズに拡大する可能性があります(下記参照)。

fast-import automatically moves active branches to inactive status based on a simple least-recently-used algorithm. The LRU chain is updated on each commit command. The maximum number of active branches can be increased or decreased on the command line with --active-branches=.高速インポートでは、最も使用頻度の低い単純なアルゴリズムに基づいて、アクティブなブランチが自動的に非アクティブ状態に移行します。LRUチェーンは各commitコマンドで更新されます。アクティブブランチの最大数は、 - active-branches =を使用してコマンドラインで増減できます。

per active treeアクティブツリーごと

Trees (aka directories) use just 12 bytes of memory on top of the memory required for their entries (see “per active file” below). The cost of a tree is virtually 0, as its overhead amortizes out over the individual file entries.ツリー(別名ディレクトリ)は、エントリに必要なメモリの上に12バイトのメモリしか使用しません(下記の「アクティブファイルごと」を参照)。ツリーのコストは、そのオーバーヘッドが個々のファイルエントリに対して償却されるため、実質的に0です。

per active file entryアクティブなファイルエントリごと

Files (and pointers to subtrees) within active trees require 52 or 64 bytes (32/64 bit platforms) per entry. To conserve space, file and tree names are pooled in a common string table, allowing the filename “Makefile” to use just 16 bytes (after including the string header overhead) no matter how many times it occurs within the project.アクティブツリー内のファイル(およびサブツリーへのポインタ)には、エントリごとに52または64バイト(32/64ビットプラットフォーム)が必要です。スペースを節約するために、ファイル名とツリー名は共通の文字列テーブルにプールされ、プロジェクト内で何回出現しても、ファイル名“ Makefile”は16バイトだけ使用できます(文字列ヘッダーのオーバーヘッドを含めた後)。

The active branch LRU, when coupled with the filename string pool and lazy loading of subtrees, allows fast-import to efficiently import projects with 2,000+ branches and 45,114+ files in a very limited memory footprint (less than 2.7 MiB per active branch).アクティブブランチLRUをファイル名文字列プールとサブツリーの遅延ロードと組み合わせると、非常に限られたメモリフットプリント(アクティブブランチあたり2.7 MiB未満)に2,000以上のブランチと45,114以上のファイルを含むプロジェクトを効率的にインポートできます。

SIGNALSシグナル

Sending SIGUSR1 to the git fast-import process ends the current packfile early, simulating a checkpoint command. The impatient operator can use this facility to peek at the objects and refs from an import in progress, at the cost of some added running time and worse compression.SIGUSR1git高速インポートプロセスに送信すると、現在のパックファイルが早く終了し、checkpointコマンドがシミュレートされます。せっかちなオペレータは、この機能を使用してオブジェクトを覗き見し、進行中のインポートを参照することができますが、実行時間が長くなり、圧縮が悪化します。

SEE ALSO関連項目

git-fast-export[1]git-fast-export [1]

GIT

Part of the git[1] suite一部のgit [1]スイート

関連記事

スポンサーリンク

<NOBR> 改行なしで表示する(NN独自の仕様)

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る