63

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

例えばgit show 962a9e8

例：https ：//github.com/joyent/node/commit/962a9e8

可能性のあるスペースが桁違いに低くなり、「わずか」2億6800万になったことを考えると、GitとGitHubはここでの衝突からどのように保護するのでしょうか。そして、彼らはそれらをどのように処理しますか？

4

3 に答える 3

64

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

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

于 2011-08-20T00:51:07.910 に答える
34

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年に作成したものです。）

于 2011-08-19T23:55:09.017 に答える
14

ここに2つのメモ：

  • yコミットを表示しているGitHubページのどこかに入力すると、そのコミットの40バイト全体が表示されます。
    これは、エンボスのポイントを示しています。GitHubは何も切り捨てません。

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

デフォルトの7は、git開発のかなり早い段階で、7桁の16進数が多かった（約2億5000万以上のハッシュ値をカバーする）ためのものです。当時、65kのリビジョンが多いと思っていました（BKでヒットしようとしていたものです）。各リビジョンは約5〜10の新しいオブジェクトになる傾向があるため、100万のオブジェクトが多数でした。

（BK = BitKeeper）

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

非現実的に小さいデフォルトの略語を増やし、gitconfigファイルでプロジェクトごとに独自のデフォルトを設定する方法を追加する必要があります。

于 2014-01-09T08:16:17.193 に答える