Subject: Re: [PATCH v3 12/35] serve: introduce git-serve

From: Brandon Williams <[email-masked]>
Date: Tue, 27 Feb 2018 10:34:07 -0800

On 02/27, Jonathan Tan wrote:
> On Fri, 23 Feb 2018 13:33:15 -0800
> Brandon Williams <[email-masked]> wrote:
> 
> > On 02/21, Jonathan Tan wrote:
> > > As someone who is implementing the server side of protocol V2 in JGit, I
> > > now have a bit more insight into this :-)
> > > 
> > > First of all, I used to not have a strong opinion on the existence of a
> > > new endpoint, but now I think that it's better to *not* have git-serve.
> > > As it is, as far as I can tell, upload-pack also needs to support (and
> > > does support, as of the end of this patch set) protocol v2 anyway, so it
> > > might be better to merely upgrade upload-pack.
> > 
> > Having it allows for easier testing and the easy ability to make it a
> > true endpoint when we want to.  As of right now, git-serve isn't an
> > endpoint as you can't issue requests there via http-backend or
> > git-daemon.
> 
> Is git-serve planned to be a new endpoint?
> 
> If yes, I now don't think it's a good idea - it's an extra burden to
> reimplementors without much benefit (to have a new endpoint that does
> the same things as upload-pack).

I'm still going to include it, with the potential for it to become an
endpoint if we so choose (it isn't now), because when we start to
introduce more things to v2 (push or other commands we haven't dreamed
up yet) it just makes more sense to contact an endpoint that doesn't
explicitly say what it does.

> 
> If not, I don't think that easier testing makes it worth having an extra
> binary. Couldn't the same tests be done by running upload-pack directly?

its builtin and not a new binary, and yes it makes testing much easier
because its assumes v2 from the start instead of v0.

-- 
Brandon Williams