Re: Git Test Coverage Report (April 30, 2020)

[Jeff King <peff@peff.net>]

On Sat, May 02, 2020 at 12:08:41AM +0200, Johannes Schindelin wrote:

> I firmly believe that this patch series, in particular the huge patch, can
> be transformed into something that looks a lot more like git.git code, is
> a lot smaller, and is a _lot_ easier to review. Without the confidence
> such a reviewable shape provides, I would actually not trust it enough to
> put it into the hands of end-users.

I agree, and I think it's not just a question of review, but of
maintenance going forward.

We are willing to accept something like compat/regex or kwset having a
vastly differing style and avoiding our usual constructs because they
are pretty stand-alone. They are modular, battle-tested pieces of code
we've taken wholesale $from elsewhere, and we're generally able to treat
them like a black box (that usually works). We really consider them a
"vendor" solution versus a system regex.

But I don't think that's the right attitude for something as critical to
Git as ref storage, or something that is mainly being used by Git (and
so we will be the likely ones to find bugs, not some third-party use).
As much as I do laud efforts to make code that can be used
out-of-the-box by other implementations, within the git.git
implementation stability and maintainability are the _most_ important
things.

Another data point to contrast with kwset, etc, is xdiff. We also took a
stylistically-unusual vendor copy of that into our tree. And I don't
think it has worked all that well. People are hesitant to touch the
code, and it has often lagged (or completely missed out) on project-wide
cleanups like those around memory allocation, size_t overflows, etc. I'd
be even more afraid to see similar issues in something as critical as
ref storage.

-Peff