Re: [PATCH v2 00/24] SHA-256 stage 4 implementation, part 1/3
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 24, 2020, 18:34 UTC
- 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:
Show 19 quoted lines
> 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.