Re: [PATCH v2 00/24] SHA-256 stage 4 implementation, part 1/3

"brian m. carlson" [off-list ref] 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.