Re: SHA256 support not experimental, or?
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Jun 30, 2023, 01:21 UTC
- Message-ID
- <ZJ4uKYIZMxi3DHo3@tapette.crustytoothpaste.net>
- In-Reply-To
- <xmqqa5wh9adg.fsf@gitster.g>
On 2023-06-29 at 22:22:51, Junio C Hamano wrote:
> True, and our messaging should avoid scaring them away from doing > so. But isn't the lack of interoperability one of the reasons why > GitHub and Gitlab do not yet offer choice of the hash? There > certainly is a chicken-and-egg problem here.
There are a lot of necessary changes for a forge to adopt SHA-256. For example, at GitHub, we have a single null OID constant in some code that has to be addressed, libgit2 has to be taught about SHA-256 or removed, and UI changes need to be done to accommodate the larger IDs. I'm sure that GitLab has very similar situations, as do all of the other forges. After all, think about the extensive number of patches that went into Git itself to get us there. Everyone has made all of those same assumptions in their forges.
I'm certain that whether or not interoperability were available would not influence the forges' desire to support SHA-256. It's simply a lot of work to fix all of those spots that need it and requires a lot of communication and discussions across teams, all of which takes time.
-- brian m. carlson (he/him or they/them) Toronto, Ontario, CA