"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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.
