web-dev-qa-db-ja.com

Githubはどのようにして短いSHAからの衝突の可能性を処理しますか？

GitとGitHubはどちらもSHAの短いバージョン（40文字すべてではなく最初の7文字のみ）を表示します。GitとGitHubはどちらも、これらの短いSHAを引数として使用できます。

例えば。 git show 962a9e8

例えば。 https://github.com/joyent/node/commit/962a9e8

可能性のあるスペースが桁違いに低くなり、「ちょうど」- 268百万 であるとすると、GitとGitHubはここで衝突からどのように保護しますか？そして、彼らはそれらをどのように扱いますか？

gitcryptographygithubsha
54
Aseem Kishore

これらの短い形式は、視覚認識を簡素化し、あなたの人生を作るためのものです 簡単 。 Gitは実際には何も切り捨てません。内部ではすべてが完全な値で処理されます。ただし、都合のよいときに部分的なSHA-1を使用できます。

部分的なSHA-1が少なくとも4文字で明確である限り、Gitは最初の数文字を入力した場合に入力する予定のコミットを理解するのに十分スマートです。つまり、現在のリポジトリ内の1つのオブジェクトのみがその部分的なSHA-1。

57
emboss

IDが000182eacf99cde27d5916aa415921924b82972cのコミットがあるリポジトリがあります。

git show 00018

リビジョンを表示しますが、

git show 0001

プリント

error: short SHA1 0001 is ambiguous.
error: short SHA1 0001 is ambiguous.
fatal: ambiguous argument '0001': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

（もし興味があれば、それはgit自体のgitリポジトリのクローンです。そのコミットは、Linus Torvaldsが2005年に作成したものです。）

30
Keith Thompson

ここで2つの注意事項：

  • 入力した場合 y コミットを表示しているGitHubページのどこかに、上記のコミットの完全な40バイトが表示されます。
    これは emboss のポイントを示しています。GitHubは何も切り捨てません。

  • とにかく2010年以来、7桁の16進数（28ビット）では十分ではありません。
    Linus Torwalds自身による commit dce9648 を参照してください（2010年10月、git 1.7.4.4）：

デフォルトの7は、Git開発のかなり早い段階であり、7桁の16進数が多かった（約2億5000万以上のハッシュ値に対応）。当時、65,000のリビジョンはたくさんあり（BKでヒットしようとしていた）、各リビジョンは約5〜10の新しいオブジェクトになる傾向があるため、100万のオブジェクトが大きな数でした。

（BK = BitKeeper）

最近では、カーネルは最大のgitプロジェクトではなく、カーネルにも約220kのリビジョンがあり（これまでのBKツリーよりもはるかに大きい）、200万に近づいていますオブジェクト。その時点で、7桁の16進数はまだそれらの多くで一意ですが、オブジェクトの数とハッシュサイズの差が2桁の場合、が発生します切り捨てられたハッシュ値の衝突。それはもはや非現実的なものに近づくことさえありません-それはいつも起こります。

現実的ではないデフォルトの省略形を増やして、git構成ファイルでプロジェクトごとにデフォルトのプロジェクトごとに設定する方法を追加する必要があります。

12
VonC