Re: RFC v3: Another proposed hash function transition plan

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sep 14, 2017, 12:39 UTC
Message-ID: <alpine.DEB.2.21.1.1709141119140.4132@virtualbox>
In-Reply-To: <20170913163052.GA27425@aiede.mtv.corp.google.com>

Hi Jonathan,

On Wed, 13 Sep 2017, Jonathan Nieder wrote:

Show 6 quoted lines

> As a side note, I am probably misreading, but I found this set of
> paragraphs a bit condescending.  It sounds to me like you are saying
> "You are making the wrong choice of hash function and everything else
> you are describing is irrelevant when compared to that monumental
> mistake.  Please stop working on things I don't consider important".
> With that reading it is quite demotivating to read.

I am sorry you read it that way. I did not feel condescending when I wrote that mail, I felt annoyed by the side track, and anxious. In my mind, the transition is too important for side tracking, and I worry that we are not fast enough (imagine what would happen if a better attack was discovered that is not as easily detected as the one we know about?).

Show 5 quoted lines

> An alternative reading is that you are saying that the transition plan
> described in this thread is not ironed out.  Can you spell that out
> more?  What particular aspect of the transition plan (which is of
> course orthogonal to the choice of hash function) are you discontent
> with?

My impression from reading Junio's mail was that he does not consider the transition plan ironed out yet, and that he wants to spend time on discussing generation numbers right now.

I was in particularly frightened by the suggestion to "reboot" [*1*]. Hopefully I misunderstand and he meant "finishing touches" instead.

As to *my* opinion: after reading https://goo.gl/gh2Mzc (is it really correct that its last update has been on March 6th?), my only concern is really that it still talks about SHA3-256 when I think that the performance benefits of SHA-256 (think: "Git at scale", and also hardware support) really make the latter a better choice.

In order to be "ironed out", I think we need to talk about the implementation detail "Translation table". This is important. It needs to be *fast*.

Speaking of *fast*, I could imagine that it would make sense to store the SHA-1 objects on disk, still, instead of converting them on the fly. I am not sure whether this is something we need to define in the document, though, as it may very well be premature optimization; Maybe mention that we could do this if necessary?

Apart from that, I would *love* to see this document as The Official Plan that I can Show To The Manager so that I can ask to Allocate Time.

Ciao, Dscho

Footnote *1*: https://public-inbox.org/git/xmqqa828733s.fsf@gitster.mtv.corp.google.com/