On Mon, Mar 27, 2023 at 11:10:40AM +0200, Johannes Schindelin wrote: > > I'm skeptical that it is a good idea for Git to implement a custom http > > server from scratch. > > To be clear: I never suggested to implement a generic HTTP server. > > All I wanted was to have a replacement for `git daemon` that speaks > https:// instead of git://. It does not have to speak to every browser out > there, it only needs to respond well when speaking to Git clients. That is > a much, much smaller surface than "production-ready server, HTTP/2 and so > on". I guess I don't see the point of having this in our test suite, though. We do want to test things like HTTP/2, SSL, and so on in our test suite. So either we have a split in our tests (some use apache, some don't, which presumably means many tests are still not run on Windows), or this custom HTTP server eventually grows to do all of those other things. I can see the utility outside the tests of a quick "let me stand up an HTTP server to access Git" tool. But even there, I'd be considered with feature creep as regular users ignore any warnings about its lack of encryption/robustness, and so on. And it feels like something that could utilize work already done by others in making a web server. Yes, that's a new dependency for the tool, but there are a lot of options out there. Surely one of them is worth building on? > And while the proposed test helper was not quite complete in that way, and > while it may have had much of the `git daemon` code that you would love to > lose, it would have offered an incremental way forward. > > I am afraid that this way forward is now blocked, and we're further away > from dropping that `git daemon` code you wanted to drop than ever. I don't see how pushing the same code into an http server helps. If we could have incrementally improved it there, we could incrementally improve it in git-daemon, too. -Peff
