Hi Brian, On Mon, 18 Jul 2016, brian m. carlson wrote: > On Mon, Jul 18, 2016 at 11:00:35AM -0700, Junio C Hamano wrote: > > Continuing this thought process, I do not see a good way to allow us > > to wean ourselves off of the old hash, unless we _break_ the pack > > stream format so that each object in the pack carries not just the > > data but also the hash algorithm to be used to _name_ it, so that > > new objects will never be referred to using the old hash. > > I think for this reason, I'm going to propose the following approach > when we get there: > > * We serialize the hash in the object formats, using multihash or > something similar. This means that it is minimally painful if we ever > need to change in the future[0]. This adds a lot of redundancy, though, and has an adverse performance impact, no? Could we not simply require packs to identify the used hash *once*, and use a single hash algorithm per repository? That would mean that we would have to re-hash packs on-the-fly if, say, talking to a SHA-1 remote from a SHA-256 local repository. > * Each repository carries exactly one hash algorithm, except for > submodule data. If we don't do this, then some people will never > switch because the submodules they depend on haven't. If we re-hash transparently, we could get away with SHA-256 even for submodules. > * If people on the new format need to refer to submodule commits using > SHA-1, then they have to use a prefix on the hash form; otherwise, > they can use the raw hash value (without any multihash prefix). > * git fsck verifies one consistent algorithm (excepting submodule > references). > > This preserves the security benefits, avoids future-proofing problems, > and minimizes performance impacts due to naming like you mentioned. > > [0] We are practically limited to 256-bit hashes because anything longer > will wrap on an 80-column terminal when in hex form. We are not really bound by the 80-column limit when choosing a hash algorithm. We typically refer to a commit by a shorter name, and the 80-column limit applies only to Git's own source code. 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