On Fri, May 14 2021, Junio C Hamano wrote: > dwh@xxxxxxxxxxxxxxxxxxx writes: > >> I think Git should externalize the calculation of object digests just >> like it externalizes the calcualtion of object digital signatures. > > The hashing algorithms used to generate object names has > requirements fundamentally different from that of digital > signatures. I strongly suspect that that fact would change the > equation when you rethink what you said above. > > We can "upgrade" digital signature algorithms fairly easily---nobody > would complain if you suddenly choose different signing algorithm > over a blob of data, as long as all project participants are aware > (and self-describing datastream helps here) and are capable of > grokking the new algorithm we are adopting. But because object > names are used by one object to refer to another, and most > importantly, we do not want a single object to have multiple names, > we cannot afford to introduce a new hashing algorithm every time we > feel like it. In other words, diversity of object naming algorithms > is to be avoided as much as possible, while diversity of signature > algorithms is naturally expected. I agree insofar that I don't see a good reason for us to support some plethora of hash algorithms, but I wouldn't have objections to adding more if people find them useful for some reason. See e.g. [1] for an implementation. But I really don't see how anything you've said would present a technical hurdle once we have SHA-1<->SHA-256 interop in a good enough state. At that point we'll support re-hashing on arrival of content hashed with algorithm X into Y, with a local lookup table between X<=>Y. So if somebody wants to maintain content hashed with algorithm Z locally we should easily be able to support that. The "diversity of naming" won't matter past that local repository, any mention of Z will be translated to X or Y on fetch/push. 1. https://lore.kernel.org/git/20191222064809.35667-1-michaeljclark@xxxxxxx/
