On 03/03/2015 12:44 AM, Junio C Hamano wrote: > [...] > I was about to suggest another alternative. > > Pretend as if Git internally used SHA-512 (or whatever hash you > want to use) instead of SHA-1, compute the object names that > way. Recompute the contents of a tree object is by replacing > the 20-byte SHA-1 field in it with a field with whatever > necessary length to hold the longer object names of elements in > the tree. > > But then a realization hit me: what new value will be placed in the > "parent " field in the commit object? You cannot have SHA-512 > variant of commit object name without recomputing the whole history. > > Now, if the final objective is to replace signature of tarballs, > does it matter to cover the commit object, or is it sufficient to > cover the tree contents? The original goal was to replace a tarball signature, for which the "alternative" that you described above seems quite elegant. If the goal were really to certify the entire history, then none of the proposals that I have seen so far is adequate anyway, because none of them propose to include better than the original SHA-1s of the parent commits. Including other metadata from the release commit does not seem useful to me; how valuable is it to know the author and commit message of the last commit that happened to make it into a release? It would be more useful to know the SHA-1 of that commit, but that would presumably be included elsewhere in the packaging data used by the distribution. > [...] Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx -- 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