On Thu, Feb 02 2023, Johannes Schindelin wrote: > 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. There's many reasons for why you almost never see a git:// URL in the wild anymore. But if "easy and painless" was synonymous with "built with git" or "ships with git" as you seem to be using it, surely it would be more common than doing the same with http or https, which requires an external server? So, easy for whom? Just us and our own test suite? Having read both your reply & Jeff's[1] I don't think you're addressing the thrust of his argument. You can share all those goals without the method of getting there requiring us to start maintaining our own webserver. > 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. I have not set up Apache on Windows, but binaries seem to be available for it[2]. We don't use those now, but is downloading, setting up & running them in CI really harder than emarking on a project of maintaining our own webserver, especially we've got an eye towards non-test suite use? Even if we think that we'd like to have a webserver built when you "make git" I don't see why we'd go the NIH route of writing our own. Unlike the git:// protocol there's a *lot* of implementations of http(s):// servers. If we think apache is too heavyweight for whatever reason, can't we add one of the many light http servers out there to contrib/ use it it from there? 1. https://lore.kernel.org/git/Y9JA0UCRh7qUqKQI@xxxxxxxxxxxxxxxxxxxxxxx/ 2. https://httpd.apache.org/docs/2.4/platform/windows.html
