Hi Brian, On Sat, 16 Jul 2016, brian m. carlson wrote: > My current plan is not to implement side-by-side data, for a couple > reasons. I am as guilty as the next person to have use the "deafbee(This is my commit, 2007-08-21)" format to refer to older commits. So I do have concerns about rewriting history when switching to a new hash. I understand the technical challenges, of course. 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 guess that it would also possible to introduce an opt-in "legacy mapper" which would generate a mapping locally of all objects' SHA-1 to whatever new hash you choose. Generating it locally would side-step the security issues of the SHA-1 algorithm. We would need to teach Git to pick that mapping up if available and use it, of course. However, that latter solution would do nothing to address the problem of existing GPG-signed commits. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html