On Tue, May 3, 2016 at 1:56 AM, David Turner <dturner@xxxxxxxxxxxxxxxx> wrote: > On Mon, 2016-05-02 at 10:51 -0700, Stefan Beller wrote: >> On Mon, May 2, 2016 at 10:43 AM, David Turner < >> dturner@xxxxxxxxxxxxxxxx> 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. 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html