Git 3.0、SHA-256移行とreftable導入で互換性の壁
Looking forward to Git 2.56 – and 3.0
Git 2.56は700以上のコミットを含むが、大きな変更は次のリリースに持ち越された。Git 3.0ではSHA-256のデフォルト化、reftableの採用、Rust必須化など互換性を破る変更が予定されている。GitHubのサポートが焦点だが、開発者brian m. carlsonは次のリリースを3.0にするのが最善だと主張。Junio Hamanoの決断が待たれる。
これは人気投票でもなければ、民主主義でもない。
HNでの議論
102- jodersky
change IDが考慮されていないのは残念だ。2025年に議論があり[1]、その後も何度か再浮上している。
基本的なアイデアは、最初の「チェンジ」に新しい種類のIDを付与するというものだ。レビュー中やコミットがrebaseされるたびに、チェンジIDは保持され、コミット自体は当然変わる。これによりツールはチェンジの過去のすべてのバージョンを識別でき、Gerrit[2]のような「コミット単位」のコードレビュー（個人的には、GitHubが標準化したブランチレビュー・スカッシュモデルよりもはるかに良い体験だと思う）を可能にする。jjでも使われているが、私は詳しくない。
現状、チェンジIDを必要とするツールは、何らかの形でコミットメッセージ本文にエンコードする必要がある。提案された議論は、チェンジIDをgitがrebaseをまたいでネイティブに保持する標準ヘッダーフィールドにすることについてだった。
[1] https://lore.kernel.org/git/[email protected]/T/#mf941...
[2] https://gerrit-review.googlesource.com/Documentation/user-ch...
- notpushkin
> LWNを0ヶ月間無料でお試しください：支払いもクレジットカードも不要です。
なんと太っ腹なオファーだ！
</aside>
- harrouet
2.56の次のバージョン番号が5.12になるのは明らかだと思っていた。
- jakub_g
reftableがデフォルトになるのを楽しみにしている。ブランチに関する多くの問題を解決してくれる。たとえば、非標準のクライアントで作成された変な文字を含むブランチがfetchを不可能にしたり、大文字小文字を区別しない「同じ」名前のブランチが同様の問題を起こしたり、FOO/Somethingが存在するためにブランチFOOを作成できなかったりする問題だ。
ブランチがディスク上のファイルでなくなれば、そうした問題はすべて消える。
私が保守しているある大規模リポジトリのセットアップスクリプトで有効にした。主な問題は、libgit2ベースの一部の個人ツール（oh-my-zshのgit statusツールなど）との非互換性だが、人は回避策を見つけるものだ。
- WCSTombs
`git add --resolved` は素晴らしいアイデアで、間違いなく使い始めるだろう。
- moebrowne
BitBucketも現在SHA256ハッシュをサポートしていないようだ。
- KolmogorovComp
これは、sha1からsha256に切り替えるときに、forcepushしてすべての履歴を書き換える必要があるということか？それは潜在的な脆弱性の大規模な原因にならないだろうか？
- GTP
なぜ直接SHA3に移行しないのか？記憶が正しければ、長さ拡張攻撃は現在SHA2では実行可能ではないが、理論的には依然として可能だ。