Hi Ævar, On Thu, 2 Feb 2023, Ævar Arnfjörð Bjarmason wrote: > On Thu, Feb 02 2023, Johannes Schindelin wrote: > > > 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. I am unwilling to accept that statement without any source to back it up. Thin air is no substitute for reliable evidence. > 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? Oh whoa... "requires an external server"? My entire point was to suggest a way forward for an _internal_ server that speaks https:// instead of git://. So I am not suggesting what you seem to have understood me to suggest. Ciao, Johannes
