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

On Tue, May 3, 2016 at 1:56 AM, David Turner [off-list ref] wrote:

On Mon, 2016-05-02 at 10:51 -0700, Stefan Beller wrote:

quoted

On Mon, May 2, 2016 at 10:43 AM, David Turner <
dturner@twopensource.com> wrote:

quoted

On Fri, 2016-04-29 at 16:34 -0700, Stefan Beller wrote:

quoted

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.

Maybe add --version to upload-pack? Then we can have a script
git-upload-pack-v2 that does "exec git upload-pack --version=2"
-- 
Duy