Gitでキレイなコミットハッシュを作る 34
ストーリー by hylom
力業 部門より
力業 部門より
Gitではコミットに対し「コミットハッシュ」と呼ばれるIDが付与されるが、このIDの先頭を「ゾロ目の数字」など特定の文字の並びにするという手法が開発された（Qiitaへの投稿：「お前らのコミットは汚い」）。
コミットハッシュは修正内容とコミット者の情報などをハッシュ関数に与えて出力したもの。開発された手法は、ハッシュ値の先頭が指定した文字と一致するまでコミット時の「Committer」情報を書き換えながらハッシュ値を計算するというもの。コミットハッシュ全体を指定した文字にするには最大で16の40乗ほどの試行が必要となるが、7桁であれば最大で16の7乗（2億6843万5456）回の試行で足りるとのことで、現実的に可能であることからこの手法を思いついたという。
偶然か必然か (スコア:2)
TorのHiddenServiceで用いられる.onionアドレス名を任意の文字列にするのと同じ手法ですね。
https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames [torproject.org]
例えば、Facebookが匿名化通信に対応、Tor専用URLを公開 [it.srad.jp]するにあたって覚えやすい.onionアドレス名(facebookcorewwwi.onion)を取得することはアドレスの入力間違いや成り済ましを抑止する意味がありますが、Gitのコミットハッシュで同じことをしても実用性皆無ですし、完全にネタ方向に振り切ってますね。
2ちゃん(5ちゃん)のトリップ探索みたい (スコア:0)
でもこれならハッシュすら要らず、0番から整数割り当ててきゃいいだけじゃないの
Re: (スコア:0)
カウンターは誰か(中央サーバー)が一意性を管理しなければならないので分散バージョン管理では不可能
これが40桁でできればSHA-1コリジョン達成 (スコア:0)
当初LinusがSHA-1コリジョンの可能性にまともに取り合わなかったためchar[40]とかがソースコード中に乱舞していたGitも最近はハッシュの情報を抽象化するようになったらしいですね。
Re: (スコア:0)
SHA-1が衝突する(攻撃ができる)という可能性と、
char[40] (ハッシュ値が40桁固定)の関連性は無いと思うけど
どういうこと？
Re:これが40桁でできればSHA-1コリジョン達成 (スコア:2)
SHA1の衝突耐性が突破されたという話とは無関係で、
単純に想定以上に大規模に利用されるようになると160オクテット（Base16で40文字）だとちょっと短すぎるかも……というだけの話でしょうね。
確率的な問題なので、SHA-512だろうが最初の1発でぶつかるかもしれないわけだけど、
それを思い煩うくらいなら、5分後に隕石で地球が滅亡する心配をするほうがましという……
Re: (スコア:0)
160ビット、だよね
1280ビットのハッシュ、いつかは必要とされるのだろうか………
Re: (スコア:0)
・SHA-1をHEXで表すと40桁になる
・後継のハッシュを格納するにはいずれも40桁では足りない
という関係がある。
マイニングじゃん (スコア:0)
マイニングチップで高速化できないかな？
Re: (スコア:0)
コインくれって感じ
こういうことをやると勘違いする奴が現われる (スコア:0)
こんなことをやってると、「ハッシュ値が汚いのでやり直せ」という
無理難題を押しつけてくるお客様が現われる予感が・・・
Re: (スコア:0)
大丈夫。そういうお客様はgitなんて使わない。
ファイル・フォルダ名に日付書いてバージョン管理だ。
Re: (スコア:0)
近年話題のマナー講師が、汚いハッシュは失礼にあたる
きれいなハッシュにする必要があるとか
言い出すのでは？
よーわからんが (スコア:0)
これローカルマシンで完結するものなの？
DDOS攻撃になったりしないの？
Re:よーわからんが (スコア:1)
ローカルマシンで完結する。元記事は読みやすいのでおすすめだ。
Re: (スコア:0)
まずgitのインストールからはじめよう。
Re: (スコア:0)
gitとは
Re: (スコア:0)
gifの仲間だと思ってる人は割と
ファイルのMD5ハッシュやSHA1ハッシュも (スコア:0)
ハッシュも、ぞろ目やら連番やら、きれいなハッシュのファイルにしてほしい
Re:ファイルのMD5ハッシュやSHA1ハッシュも (スコア:1)
コミット番号を指定するときに先頭数桁で指定可能、COmmiter情報はあまりみんな気にしない…
というgitの仕様があるからの話であって、ファイルの場合はあまりその恩恵を感じないんだよなぁ…
例えばソースコード末尾にタブ、改行、空白をつける…とかいう手法で
同じようなことができそうだけど、７桁をきれいにするだけでも「最大で16の7乗」
と考えると、ファイルサイズがものすごいことになりそうだなぁ。
# mishimaは本田透先生を熱烈に応援しています
Re:ファイルのMD5ハッシュやSHA1ハッシュも (スコア:1)
> 例えばソースコード末尾にタブ、改行、空白をつける…とかいう手法で
プリコミットフックでフォーマッター通されて消えてしまうというオチが……
Re:ファイルのMD5ハッシュやSHA1ハッシュも (スコア:2)
むしろフォーマッターに実装する方向で（１コミットに何時間かかるんだ）
# mishimaは本田透先生を熱烈に応援しています
Re: (スコア:0)
や、計算量は肥大化してもファイルサイズは肥大化せんでしょ。7桁をきれいにするだけなら7バイトで済む。そのままだとテキストエディタで編集できなくなるからBASE64エンコードしたり元記事のように16進数を文字列で書き表すHEXエンコードしても最大14バイトで事足りる。
Re:ファイルのMD5ハッシュやSHA1ハッシュも (スコア:1)
見た目（とビヘイビア）を変えないように「タブ、改行、空白」という縛りを考慮に入れてるんですよ。
（なおソースコードの言語がwhitespaceである可能性は考慮しない）
コメントに意味不明の内容が書かれていることを許容するなら、もちろん14バイト＋コメント記述用のその言語固有の文字列、のサイズで済むのだろうけどね。
# mishimaは本田透先生を熱烈に応援しています
Re: (スコア:0)
なるほど……いや、それにしても「タブ、改行、空白」（改行はCRとLF）の4種類の文字を基底にエンコードするなら、高々桁数の4倍のバイト数＋コメント記述用のその言語固有の文字列、のサイズで済むのでは。
Re:ファイルのMD5ハッシュやSHA1ハッシュも (スコア:1)
おっと、単一記号の追加ではなくて組み合わせならご指摘の通りですね。
whitespace のことを思い出すくらいなら組み合わせを考えてしかるべきでした。
# mishimaは本田透先生を熱烈に応援しています
Re: (スコア:0)
車の希望ナンバーみたいなもんですか。
数字に意味なんかないはずなのに、お好みの数字にしたい！というやつ。
Srad民が毛嫌いしそうな (スコア:0)
印鑑を左に傾けるのと何が違うの？
Re:Srad民が毛嫌いしそうな (スコア:2, すばらしい洞察)
あっちは本気、こっちはネタ。
「最大」ってなんで？ (スコア:0)
説明とGitHubにあるコードを見る限り、1/16^7 の確率で当たるガチャを、当たるまでひたすら繰り返しているだけのように見えるので、最大で 16^7 回やれば必ず当たるとは全く保証されていないように見えるのですが、何か勘違いしているのでしょうか。
Qiitaの記事を書いてある本人も「総当たり」と言っているので気になります。
Re: (スコア:0)
そこで自分で検証してみるかどうかがQiita民とスラド民の違いなんだろうなと思った。
Re: (スコア:0)
最大っていうのは誤りですね。
期待値が16 ^ 7回だと思います
最悪計算量は∞かと
この回数の試行が現実的って… (スコア:0)
進歩してるんだなぁと（小並感）