Hi Ævar,
On Thu, 2 Feb 2023, Ævar Arnfjörð Bjarmason wrote:
On Thu, Feb 02 2023, Johannes Schindelin wrote:
quoted
On Thu, 26 Jan 2023, Junio C Hamano wrote:
quoted
Jeff King [off-list ref] writes:
quoted
quoted
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