Thread (1 message) 1 message, 1 author, 2017-09-06

Re: RFC v3: Another proposed hash function transition plan

From: Junio C Hamano <hidden>
Date: 2017-09-06 06:28:30

Jonathan Nieder [off-list ref] writes:
Linus Torvalds wrote:
quoted
On Fri, Mar 3, 2017 at 5:12 PM, Jonathan Nieder [off-list ref] wrote:
quoted
quoted
This document is still in flux but I thought it best to send it out
early to start getting feedback.
This actually looks very reasonable if you can implement it cleanly
enough.
Thanks for the kind words on what had quite a few flaws still.  Here's
a new draft.  I think the next version will be a patch against
Documentation/technical/.
Can we reboot the discussion and advance this to v4 state?
As before, comments welcome, both here and inline at

  https://goo.gl/gh2Mzc
I think what you have over there looks pretty-much ready as the
final outline.

One thing I still do not know how I feel about after re-reading the
thread, and I didn't find the above doc, is Linus's suggestion to
use the objects themselves as NewHash-to-SHA-1 mapper [*1*].  

It does not help the reverse mapping that is needed while pushing
things out (the SHA-1 receiver tells us what they have in terms of
SHA-1 names; we need to figure out where we stop sending based on
that).  While it does help maintaining itself (while constructing
SHA3-content, we'd be required to find out its SHA1 name but the
SHA3 objects that we refer to all know their SHA-1 names), if it is
not useful otherwise, then that does not count as a plus.  Also
having to bake corresponding SHA-1 name in the object would mean
mistakes can easily propagate and cannot be corrected without
rewriting the history, which would be a huge downside.  So perhaps
we are better off without it, I guess.


[Reference]

*1* [ref]

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help