Hi Brian, On Sun, 17 Jul 2016, brian m. carlson wrote:
> On Sun, Jul 17, 2016 at 10:01:38AM +0200, Johannes Schindelin wrote: > > Out of curiosity: have you considered something like padding the SHA-1s > > with, say 0xa1, to the size of the new hash and using that padding to > > distinguish between old vs new hash? > > I'm going to end up having to do something similar because of the issue > of submodules. Submodules may still be SHA-1, while the main repo may > be a newer hash. I was going to zero-pad, however. I thought about zero-padding, but there are plenty of is_null_sha1()/is_null_oid() calls around. Of course, I assumed left-padding. But you may have thought of right-padding instead? That would make short name handling much easier, too. FWIW it never crossed my mind to allow different same-sized hash algorithms. So I never thought we'd need a way to distinguish, say, BLAKE2b-256 from SHA-256. Is there a good reason to add the maintenance burden of several 256-bit hash algorithms, apart from speed (which in my mind should decide which one to use, always, rather than letting the user choose)? It would also complicate transport even further, let alone subtree merges from differently-hashed repositories. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
