All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Turner <dturner@twopensource.com>
To: Stefan Beller <sbeller@google.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH 03/14] upload-pack-2: Implement the version 2 of upload-pack
Date: Mon, 02 May 2016 14:56:15 -0400	[thread overview]
Message-ID: <1462215375.4123.69.camel@twopensource.com> (raw)
In-Reply-To: <CAGZ79kavBUohoMcC3iEws5mVBQ6HZsR=HyBoxM1jxUVJ6Z1jkA@mail.gmail.com>

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.

  reply	other threads:[~2016-05-02 18:56 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 [this message]
2016-05-03  0:31         ` Duy Nguyen
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1462215375.4123.69.camel@twopensource.com \
    --to=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. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.