From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 24 Feb 2020 18:34:20 GMT
Subject: Re: [PATCH v2 00/24] SHA-256 stage 4 implementation, part 1/3
Message-ID: <xmqqy2srq1g3.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20200222201749.937983-1-sandals@crustytoothpaste.net>

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> This is a series for part 1 of 3 of a stage 4 SHA-256 implementation.
> It is mostly the same as v1[0], which was RFC.  The interested reader is
> referred there for the in-depth explanations.
>
> A few interesting changes have taken place since v1.  First, I
> discovered a regression in a recent series which introduced a hard-coded
> constant, so patch 1 addresses this.
>
> Second, I discovered a mistaken assumption that we were making about our
> hash implementations: that copying the struct was sufficient to copy the
> context.  This is not true for libgcrypt, where our context is a pointer
> instead, so patch 2 addresses this with a helper function.
>
> Finally, I've added a check to prevent non-developers from creating
> SHA-256 repositories, since this series is not sufficient to implement
> full SHA-256 support.  Even as a developer, creating a SHA-256
> repository immediately leads to a broken state, since we don't recognize
> the extension (yet) and therefore promptly refuse to operate on it in
> any way.  Preventing this experience seemed prudent.

I am very tempted to take 1/24 separately and queue it at the tip of
the jk/packfile-reuse-cleanup topic.

I didn't read the fast-import bits at the end of the series, but
everything before those steps made sense to me.

Thanks.