From: Duy Nguyen <pclouds@gmail.com>
To: David Turner <dturner@twopensource.com>
Cc: Stefan Beller <sbeller@google.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH 03/14] upload-pack-2: Implement the version 2 of upload-pack
Date: Tue, 3 May 2016 07:31:02 +0700 [thread overview]
Message-ID: <CACsJy8DxwQKcno0ikZCDZUQ3xAd-iWw9mqSGnzgb5GqdRwHsYA@mail.gmail.com> (raw)
In-Reply-To: <1462215375.4123.69.camel@twopensource.com>
On Tue, May 3, 2016 at 1:56 AM, David Turner <dturner@twopensource.com> 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@twopensource.com> 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
next prev parent reply other threads:[~2016-05-03 0:31 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-29 23:34 [WIP PATCH 00/14] Protocol v2 patches Stefan Beller
2016-04-29 23:34 ` [PATCH 01/14] upload-pack: make client capability parsing code a separate function Stefan Beller
2016-04-29 23:34 ` [PATCH 02/14] upload-pack.c: Refactor capability advertising Stefan Beller
2016-04-30 1:04 ` David Turner
2016-05-04 20:05 ` Junio C Hamano
2016-04-29 23:34 ` [PATCH 03/14] upload-pack-2: Implement the version 2 of upload-pack Stefan Beller
2016-05-02 17:43 ` David Turner
2016-05-02 17:51 ` Stefan Beller
2016-05-02 18:56 ` David Turner
2016-05-03 0:31 ` Duy Nguyen [this message]
2016-05-04 20:11 ` Junio C Hamano
2016-04-29 23:34 ` [PATCH 04/14] connect: rewrite feature parsing to work on string_list Stefan Beller
2016-05-02 18:18 ` David Turner
2016-05-02 18:46 ` Stefan Beller
2016-05-04 20:13 ` Junio C Hamano
2016-05-17 22:23 ` David Turner
2016-04-29 23:34 ` [PATCH 05/14] transport: add infrastructure to support a protocol version number Stefan Beller
2016-04-29 23:34 ` [PATCH 06/14] remote.h: add get_remote_capabilities, request_capabilities Stefan Beller
2016-05-02 18:57 ` David Turner
2016-05-03 5:33 ` Jeff King
2016-05-03 21:21 ` David Turner
2016-05-04 16:44 ` Stefan Beller
2016-04-29 23:34 ` [PATCH 07/14] fetch-pack: move capability selection out of do_fetch_pack Stefan Beller
2016-04-29 23:34 ` [PATCH 08/14] fetch-pack: factor out get_selected_capabilities_list Stefan Beller
2016-05-02 19:09 ` David Turner
2016-04-29 23:34 ` [PATCH 09/14] fetch-pack: Add negotiate_capabilities Stefan Beller
2016-04-29 23:34 ` [PATCH 10/14] do_fetch_pack: select capabilities for transport version 1 only Stefan Beller
2016-04-29 23:34 ` [PATCH 11/14] builtin/fetch-pack: add argument for transport version Stefan Beller
2016-04-29 23:34 ` [PATCH 12/14] Add test for fetch-pack Stefan Beller
2016-05-02 19:45 ` David Turner
2016-04-29 23:34 ` [PATCH 13/14] WIP add test for git pull Stefan Beller
2016-04-29 23:34 ` [PATCH 14/14] WIP test git fetch Stefan Beller
2016-05-02 20:41 ` [WIP PATCH 00/14] Protocol v2 patches David Turner
2016-05-02 20:43 ` Stefan Beller
2016-05-24 22:46 ` David Turner
2016-05-24 23:03 ` Duy Nguyen
2016-05-25 16:45 ` David Turner
2016-05-25 16:23 ` Junio C Hamano
2016-05-25 19:31 ` David Turner
2016-05-25 21:29 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACsJy8DxwQKcno0ikZCDZUQ3xAd-iWw9mqSGnzgb5GqdRwHsYA@mail.gmail.com \
--to=pclouds@gmail.com \
--cc=dturner@twopensource.com \
--cc=git@vger.kernel.org \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).