Martin Ågren <martin.agren@xxxxxxxxx> writes: >> I'm fine with marking the functionality experimental for a few releases, >> since it is possible we have bugs people haven't found, and adding a >> note about interoperability after that point, since I think that's a >> fair and valuable issue. I think if we go a few releases without any >> major issues, we can change this to the following: >> >> Note that a SHA-256 repository cannot yet share work with "regular" >> SHA-1 repositories. Many tools do not yet understand SHA-256 >> repositories, so users may wish to take this into account when >> creating new repositories. > > With respect, I think that's too aggressive. By that time, we may > conclude that, e.g., the "v2 pack indices with SHA-256" file handling is > robust. But I'd be surprised if using `git init --object-format=sha256` > in June 2021 won't cause *some* extra work for users or ourselves > further down the line compared to using a regular SHA-1 `git init`. > Pushing to a SHA-1 hosting service will become *possible* at some point, > but maybe it won't be *efficient enough to be practical in the real > world* until some time after that. IOW, you question "if we go a few releases without any major issues" part? I tend to agree that for a large change like this, a few releases may not be sufficiently long time for a feature that is marked as experimental in big flashing red letters to get exercised enough to get major issues noticed. > All those other, *new* file formats outlined in the hash > transition document won't exist at that time (at least not in master). > > Now would probably be a good time to update the hash transition > documents, first of all to tick off what we've already done, and second, > to reassess the rest. Yes, it is a good idea to stop and see where in the overall large picture we currently are. Thanks.
