On Wed, Sep 08 2021, Johannes Schindelin wrote: > [...] > Which means that I want to weigh how much effort to put into polishing an > unlikely code path on one side, and on the other side how much effort to > put into moving the functionality away from `contrib/` and deleting that > unlikely code path. > > In the same vein, while this patch series contains (mostly) code in > `contrib/` (and therefore technically does not need to adhere strictly to > Git's code style), it is probably wise to pay closer attention to the code > style particularly in those parts that are prone to be moved verbatim (or > close to verbatim) to Git proper. I don't think we have any such exception to our usual style & preferred code patterns in contrib/* or compat/* in general. In the latter case we have e.g. compat/regex/ and other externally-imported codebases, which we've tried to stylistically modify as little as possible to make subsequent imports easier, ditto sha1dc/ etc. I think the general (but unwritten) rule has been to draw the distinction on whether or not code is still externally maintained and expected to be imported, or if it's expected to be maintained in git.git going forward. I think that this proposed series falls thoroughly in the latter category, but maybe I've misunderstood it.. Also re my [1] I had some (still relevant, but unaddressed) points on v1 about how placing this in contrib/* made certain aspects of integrating it into our build system harder. I was imagining that distinction as purely an internal implementation detail to git.git (make install etc. would behave the same), but per the above it seems to come with deeper connotations than that at least in your mind. 1. https://lore.kernel.org/git/87r1dydp4m.fsf@xxxxxxxxxxxxxxxxxxx
