From: Kristoffer Haugsbakk Date: Tue, 06 Oct 2026 16:16:07 GMT Subject: Re: [RFC PATCH 0/4] sign a SHA-256 digest of the tree in commits and tags Message-ID: In-Reply-To: On Mon, Oct 5, 2026, at 14:41, Patrick Steinhardt wrote: > On Mon, Oct 05, 2026 at 11:32:54AM +0200, Scott Chacon wrote: >> On Fri, Oct 2, 2026 at 9:06 PM brian m. carlson >> wrote: >> > On 2026-10-02 at 08:18:42, Scott Chacon wrote: > [snip] >> > Every major forge has support >> > for SHA-256, whether publicly or in preview, >> >> Nobody has access to this for GitHub, which is where almost all usage >> is and where the kinks could theoretically have been ironed out. If >> 3.0 comes out in March, there will have been no time for anyone to >> give feedback or make substantial changes before everyone is forced >> into real usage of this highly incompatible change. >> >>[snip even more] >> >> As one small but interesting example, I'm honestly fascinated that >> there is only now a thread here about the GitHub specific usability >> issues [2] with mixed odb repos (between several GitHub-y people, >> nonetheless) that hasn't been previously considered (the "limbo" >> idea). This is the kind of thing (among many others, I'm sure) that >> would come up if people had time to use this at all before a default >> switch. > > The biggest problem I have is that the ecosystem has been entirely > unwilling to do anything about the SHA-256 move before we announced that > this is going to become mandatory. Only then were developers even able > to convince anybody (especially those paying the wages) to get the time > to implement support for it. > > So there is some kind of ossification happening in the space. But things > are finally moving now that the due-date is drawing closer. I would be > extremely hesitant to change course again and drop this breaking change > now that there finally is some movement. Because the only consequence of > that would be that the ecosystem will stop working on it again. And even > more so, I would even expect that this will make the next time we want > to do a breaking change exponentially harder as the lesson learned is > that nobody needs to do anything. > > Maybe I'm too pessimistic about this, but I don't think so. We've been > working on this whole transition for almost a decade by now, and only > now where we're forcing the ecosystem to adapt are large players like > GitHub even moving. The wider ecosystem is one thing. But git(1) itself doesn’t seem ready at all. A few days ago, having read Scott Chacon’s blog post and discussions around it,[1] I wanted to test migrating the Git repo to SHA-256. So how do I do that? I google around and the most official “transition” program seems to be this. https://git-scm.com/docs/hash-function-transition I.e. a document where you can’t really tell the implementation from the aspiration. † 1: It seems he has never linked it here on the list, like in this thread. But okay, the *real* program to convert a repository seems to be git fast-export --all And that was okay. The Git repo seems to have a bit of cruft, and git-fast-export(1) fails on the first error then suggests a fix so that you can continue on to the next error. But that’s fine for a one-shot program. For anyone interested: git fast-export --all --reencode=yes --mark-tags \ --signed-tags=verbatim \ --tag-of-filtered-object=rewrite >SHA1HERE Some real loss of fidelity was there though: 1. You can’t for some reason export refs that point to blobs or trees 2. Your Git notes will be effectively lost since they will retain their SHA-1 filenames. (This is mentioned in hash-function-transition) Then you import it with git fast-import But to no one’s surprise (here) this does not work because of the SHA-1 collision submodule. Okay, dropping that exercise for a second. I would personally be okay with trying out this migration on my existing repos that are “local only”. It would clearly be in my interest to find any bugs that are particular to my workflows. But for that I would that migration where you keep a mapping of SHA-1 to SHA-256. Or else I will lose Git notes forever (which I use a lot). But reading brian’s cousin response: ... it seems that there is not enough in git(1) or anywhere else to do that. So what is anyone outside the group of guts-of-Git developers supposed to do? It seems we just have to wait until Git 3.0 and see what happens. And then you can imagine Git 3.0. Someone happens to make a new Git repository and they use it for three days without trying to push it somewhere to SHA-1-Only land. But then they do. And the forge has at least implemented a nice, informative error message. The user only cares that “a week ago it worked” and “now it is broken”. (“broken” subjectively.) He feeds it to some oracle and it turns out that they just need a few commands to convert back to SHA-1, then one command to turn off the default. Now they have mitigated the “broken Git” problem for themselves. And what have they lost? It’s not even a hack. Then zoom out and you might have the wider ecosystem, like forges. If they don’t implement it in time? Well, maybe that informative error message becomes: remote: unsupported hash algorithm remote: if this is your first push of a local repo, here’s remote: how to convert your repo to SHA-1: remote: remote: and here’s how to turn off this default [...] Then someone will post that as a question on StackOverflow, get flamed because the error message “says how to fix it”, get 3000 upvotes, and the world moves drunkenly on. The above scenario would be very hyperbolic and too cynical if not for the context: one person is leading the direct implementation work[2] in their spare time. In order to migrate Git from a to-be government-wide banned hash algorithm. That seems like an institutional malfunction. Somewhere. To reiterate, there doesn’t seem like there is anything for us above-average Git-interested users to do yet. So it feels like we just have to wait until March or a little later, see if the default- SHA-256 change lands, and see what the fallout is. And that is a bit frustrating. † 2: This is to acknowledge that there are other people like reviewers