Hi Junio & Peff, On Thu, 26 Jan 2023, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > >> Thanks, both. Let's merge it down. > > > > Sorry, I'm a bit late to the party, but I left some comments just now > > (this topic had been on my review backlog for ages, but I never quite > > got to it). > > > > Many of my comments were small bits that could be fixed on top (tiny > > leaks, etc). But some of my comments were of the form "no, do it totally > > differently". It may simply be too late for those ones, but let's see if > > Matthew finds anything compelling in them. > > I do not mind reverting the merge to 'next' to have an improved > version. Your "do we really want to add a custom server based on > questionable codebase whose quality as a test-bed for real world > usage is dubious?" is a valid concern. Except. Except that this code base would have made for a fine base to potentially implement an HTTPS-based replacement for the aging and insecure git-daemon. That code base (which is hardly as questionable codebase as you make it sound because it has been in use for years in a slightly different form) would have had the opportunity to mature in a relatively safe environment: our test suite. And eventually, once robust enough, it could have been extended to allow for easy and painless yet secure ad-hoc serving of Git repositories, addressing the security concerns around git-daemon. And now that we're throwing out that code we don't have that opportunity, making the goal to deprecate the git-daemon and replace it by something that is as easy to set up but talks HTTPS instead much, much harder to reach. In addition, it causes a loss of test coverage because Apache is not available in all the setups where the "questionable" code would have had no problem being built and validating the credential code. Windows, for example, will now go completely uncovered in CI regarding the new code. Ciao, Johannes
