3

タイトルにもある通り、

彼らはどういう意味ですか:

ディスク上のフットプリントと I/O オーバーヘッドを削減するために、インデックス ファイルの実験的な「バージョン 4」形式が導入されました。

さらに重要なことは、この変更によって下位互換性が失われるリスクがあるか、またはこの変更によってリポジトリが破損する可能性があるかということです。

いくつかのテストを行うと、下位互換性があり、悪影響は明らかにされていないことが示唆されます.

msysgit 1.7.11 に対するこの変更が実際に何を意味するのか、誰かが明確にしてくれませんか?

4

1 に答える 1

2

これは git リポジトリ自体と同じ変更であるため (msysgit と git の間、または Git の以前のリビジョンとの間)、互換性の問題はありません (公式の Git リポジトリでは互換性の問題について言及されていません)。

gitリポジトリDocumentation/technical/index-format.txtで、GIT インデックス形式に関するファイルを参照してください。

(バージョン 4) バージョン 4 では、エントリ パス名は、前のエントリのパス名に対してプレフィックス圧縮されます (最初のエントリは、前のエントリのパス名が空の文字列であるかのようにエンコードされます)。
エントリの先頭に、可変幅エンコーディングの整数(パック エントリの場合N、オフセットと同じエンコーディングがエンコードされます。 pack-format.txtを参照) が格納され、その後に NUL で終了する文字列が続きます。 前のエントリのパス名の末尾からバイトを削除し、それを文字列に置き換えると、このエントリのパス名が生成されます。OFS_DELTAS
NS

必要に応じて 1 ~ 8 個の nul バイトを使用して、名前を NUL で終了させたまま、エントリを 8 バイトの倍数にパディングします。

(バージョン 4) バージョン 4 では、パス名の後のパディングは存在しません。

したがって、これは実際にはインデックスエントリの内部管理であり、git (1.7.11 またはその他のバージョン) がリモート リポジトリを複製/読み取ることを妨げるものではありません。 「エントリパス名」の表現を最適化することのみを目的としています。

于 2012-07-25T06:54:17.293 に答える