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
