Subject: Re: [PATCH 03/14] upload-pack-2: Implement the version 2 of upload-pack

From: David Turner <[email-masked]>
Date: Mon, 02 May 2016 14:56:15 -0400

On Mon, 2016-05-02 at 10:51 -0700, Stefan Beller wrote:
> On Mon, May 2, 2016 at 10:43 AM, David Turner <
> [email-masked]> wrote:
> > On Fri, 2016-04-29 at 16:34 -0700, Stefan Beller wrote:
> > > In upload-pack-2 we send each capability in its own packet
> > > buffer.
> > > The construction of upload-pack-2 is a bit unfortunate as I would
> > > like
> > > it to not be depending on a symlink linking to upload-pack.c, but
> > > I
> > > did
> > > not find another easy way to do it. I would like it to generate
> > > upload-pack-2.o from upload-pack.c but with '
> > > -DTRANSPORT_VERSION=2'
> > > set.
> > 
> > Couldn't we check argv[0] and use that to determine protocol?  Then
> > we
> > could symlink executables rather than source code.
> 
> IIRC I proposed a similar thing earlier, i.e.
> 
>     if (argv[0] ends with 2)
>         do_protocol_v_2(...)
> 
> but that may break (and confuse a lot!) some use cases.
> `git fetch` has the documented --upload-pack switch, so as a server
> -admin
> you are free to have git-upload-pack linking to
> "git-upload-pack-2.8" but additionally you still have
> "git-upload-pack-1.7" or "git-upload-pack-custom-2".
> 
> so I think we should not do that :(
> I do like to symlink the executables though.

I think it would probably not break anyone if the new executable name
were sufficiently distinctive -- e.g. starts_with (strrchr(argv[0],
'/'), "git-upload-pack-protocol-v2"). But it would make custom
executables a bit more complicated for the future.

I guess it is better to have silly source code but clean binaries than
clean source code but silly user-visible rules.