Is there at this point a solid plan for how SHA-256 repos will support access SHA-1 only clients? I remember reading a discussion of having a table somewhere that would translate SHA-256 to SHA-1 when needed. I had a brainstorm which is probably the uniformed opinion of an outsider. I was thinking in server settings that a well-packed pack of all of the objects is kept to make it quick for git clone to do it's work. I was thinking perhaps in a repo that wanted to support access from SHA-1 clients it might makes sense to have three packs instead of the standard 1. A pack of all of the blobs with no oid references. So that either a SHA-256 or a SHA-1 client could consume it (modulo header changes that are needed). The pack of blobs could have both an ordinary SHA-256 index and a SHA-1 index. Then there could be two packs of metadata (aka trees and commits and tags that embed oids). One pack in SHA-256 and one pack in SHA-1. Then with a little header surgery git clone could be served with sendfile and gluing the pack of blobs and pack of object together. In the normal end user client case that is doesn't seem to make a lot of sense as all that is needed is to figure out which oid to use and always display SHA-256. My naivete suggests that just keeping the SHA-1 metadata in a SHA-256 repo could be simple enough to implement that it would allow the transition to start happening, and it could be optimized away later. Eric
