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. -- 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