>> I think converting is a much better option. Use a single-hash storage, and >> convert everything to that on import/clone/pull. > > That ignores two very important issues that I already had mentioned:
That's not true. If you double-check the next part of my message, you I just showed that an automatic two-way mapping could solve these problems! (I even give briefs explanation how to handle referencing and signature verification in those cases.) My point is not to throw out old hashes and break signatures. My point is to convert the data storage, and use mapping to resolve problems with those old hashes and signatures. A single-hash data storage is obviously way easier to handle, than a multi-hash mass. (See Linus's old e-mail: multiple hashes [=meaning database keys] for the same content is a complete nonsense in git-speak) > The "convert everything" strategy also ignores the problem of interacting > with servers and collaborators. Think of hosting repositories, > rediscovering forgotten work trees, and of the "D" in DSCM. That's not an issue when we're working with a single repository. It's reasonable to ask for all git clients of the same repository, to support the same hash. Yes, you have the need to configure the hash algo on a per-repository basis but that's all. For importing and co-working between different repositories, it's a bit harder, problem, but it's possible to handle the conversions correctly. -- 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
