在 Hacker News 首頁上的「Whatever happened to SHA-256 support in Git?」這篇，大概半年前，今年六月的文章，在講 Git 在 SHA-256 支援上遇到的問題。
最大的問題還是沒有 transition plan：
Bjarmason pointed out that there is still no interoperability between SHA-1 and SHA-256 repositories, and that none of the Git hosting providers appear to be supporting SHA-256.
這點導致了目前場上看的到的服務與 open source 軟體都沒有支援的計畫，這點算是一個超級失敗的 transition plan。
Git是一種源代碼管理系統，它使用散列函數將每個對象（例如文件的每個版本）和每個提交都轉換為一個數值，用於存儲該對象。散列函數的安全性是整個倉庫完整性的重要組成部分。如果攻擊者可以用具有相同散列值的另一個提交替換提交，他們可能會在不冒檢測風險的情況下將惡意代碼植入倉庫中。這種前景令任何依賴 Git 倉庫中代碼安全性的人感到擔心，也就是所有人。
Git 項目早已選擇 SHA-256 作為 SHA-1 的替代品。Git 最初是使用 SHA-1 寫成的，但是這些代碼已被重構，並且可以處理多種散列類型，其中 SHA-256 是第二種支持的類型。現在可以使用 SHA-256 創建 Git 倉庫（只需使用 --object-format=sha256 標誌），大多數本地操作都會正常工作。Git 中支持替代散列算法的基礎是2020年發布的2.29版本的一部分，並且似乎很穩定。
然而，自從2021年3月發布的2.31版本中出現了修復程序以來，2.29版本是最後一個在任何重大方面支持替代散列的版本。專
續寫前文，Git 專案在支持 SHA-256 之前一直使用 SHA-1 作為散列算法。然而，由於 SHA-1 的終極破解，Git 項目被迫尋找替代方案。Git 原本的代碼是深深地嵌入 SHA-1 的，但是這些代碼已經被重構，並且可以處理多種散列類型，其中 SHA-256 是第二種支持的類型。因此，現在可以使用 SHA-256 創建 Git 倉庫（只需使用 --object-format=sha256 標誌），大多數本地操作都會正常工作。
然而，目前尚不存在 SHA-1 和 SHA-256 倉庫之間的相互操作性，並且 Git 托管提供商似乎都不支持 SHA-256。這種支持（或缺乏支持）很重要，因為無法推送到 Git 熔爐的倉庫對許多人來說將是無用的。此外，使用 SHA-256 的較長散列可能會破壞 Git 項目以外開發的工具，這種風險也無法完全消除。整體而言，這是一種尚未準備好用於現實世界的功能。
雖然如此，值得注意的是，迄今為止完成大部分散列轉換工作的 brian m. carlson 對 Bjarmason 的評估持不同看法。在他看來，目前唯一“可以辯解
的”使用 SHA-1 的原因是與 Git 熔爐提供商的相互操作性。否則，他認為 SHA-1 已經過時，並且使用 SHA-256 的性能可能“大幅提升”。但是，他同意所需的相互操作性目前尚不存在，且沒有人表示它即將在短期內到來。
因此，目前看來，Git 專案在支持 SHA-256 方面的工作似乎已經停止。至於什麼原因導致了這種情況，目前還不清楚。但是，這並不意味著 Git 將永遠不會支持 SHA-256 或其他散列算法。相反，可能是因為尚未解決所有技術問題，或者可能是因為其他原因（例如技術資源有限）。無論原因是什麼，重要的是要記住，Git 項目的開發人員一直在努力使其更強大、更安全，並且將繼續努力。