From: "Shawn O. Pearce" <spearce@spearce.org>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH 4/8] Support remote helpers implementing smart transports
Date: Tue, 1 Dec 2009 11:22:33 -0800 [thread overview]
Message-ID: <20091201192233.GL21299@spearce.org> (raw)
In-Reply-To: <1259675838-14692-5-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
> index 5cfdc0c..adf815c 100644
> --- a/Documentation/git-remote-helpers.txt
> +++ b/Documentation/git-remote-helpers.txt
> @@ -90,6 +90,28 @@ Supported if the helper has the "push" capability.
> +
> Supported if the helper has the "import" capability.
>
> +'connect-r' <service>::
> + Connects to given service. Stdin and stdout of helper are
> + connected to specified service (no git or git- prefixes are used,
> + so e.g. fetching uses 'upload-pack' as service) on remote side.
This flies against every other convention we have. git:// uses the
string 'git-upload-pack' and 'git-receive-pack', and so does the
smart-http code. We should continue to use the git- prefix here,
to be consistent, even though by context its clearly implied.
> + Valid replies to this command are 'OK' (connection established),
Why 'OK'? Currently remote-helpers return an empty blank line
to any successful command, not 'OK'.
> + 'FALLBACK' (no smart transport support, fall back to dumb
> + transports) and 'ERROR' (can't connect, don't bother trying to
> + fall back).
FALLBACK almost makes sense, but ERROR we don't do in the
the existing helper protocol. Instead the helper simply
prints its error message(s) to stderr and does exit(128).
aka what die() does.
> +Supported if the helper has the "connect-r" capability. Not used if
> +helper has the "invoke-r" capability, as invoke is preferred to connect.
> +
> +'invoke-r' <cmdlength> <cmd>::
> + Like connect-r command, but instead of service name, command
> + line is given. The length of command field is given in command
> + length field.
> ++
> +Supported if the helper has the "invoke-r" capability.
Why both connect-r and invoke-r? Why isn't connect-r sufficient
here? Isn't it sufficient for any service that runs over git:// ?
--
Shawn.
next prev parent reply other threads:[~2009-12-01 19:22 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-01 13:57 [RFC PATCH 0/8] Git remote helpers to implement smart transports Ilari Liusvaara
2009-12-01 13:57 ` [RFC PATCH 1/8] Pass unknown protocols to external protocol handlers Ilari Liusvaara
2009-12-01 13:57 ` [RFC PATCH 2/8] Refactor git transport options parsing Ilari Liusvaara
2009-12-01 13:57 ` [RFC PATCH 3/8] Support taking over transports Ilari Liusvaara
2009-12-01 13:57 ` [RFC PATCH 4/8] Support remote helpers implementing smart transports Ilari Liusvaara
2009-12-01 19:22 ` Shawn O. Pearce [this message]
2009-12-02 5:55 ` Ilari Liusvaara
2009-12-02 17:04 ` Shawn O. Pearce
2009-12-02 20:10 ` Ilari Liusvaara
2009-12-03 19:42 ` Shawn O. Pearce
2009-12-02 17:12 ` Shawn O. Pearce
2009-12-01 13:57 ` [RFC PATCH 5/8] Support remote archive from external protocol helpers Ilari Liusvaara
2009-12-01 13:57 ` [RFC PATCH 6/8] Remove special casing of http, https and ftp Ilari Liusvaara
2009-12-01 18:24 ` Shawn O. Pearce
2009-12-01 19:39 ` Ilari Liusvaara
2009-12-01 19:15 ` Daniel Barkalow
2009-12-02 5:52 ` Ilari Liusvaara
2009-12-01 13:57 ` [RFC PATCH 7/8] Add remote helper debug mode Ilari Liusvaara
2009-12-01 13:57 ` [RFC PATCH 8/8] Support mandatory capabilities Ilari Liusvaara
2009-12-01 16:12 ` [RFC PATCH 0/8] Git remote helpers to implement smart transports Sverre Rabbelier
2009-12-01 16:52 ` Shawn O. Pearce
2009-12-01 17:19 ` Ilari Liusvaara
2009-12-01 19:30 ` Shawn O. Pearce
2009-12-01 20:42 ` Junio C Hamano
2009-12-01 23:20 ` Shawn O. Pearce
2009-12-02 5:56 ` Ilari Liusvaara
2009-12-02 6:35 ` Junio C Hamano
2009-12-02 16:04 ` Ilari Liusvaara
2009-12-02 17:26 ` Junio C Hamano
2009-12-02 17:39 ` Johannes Schindelin
2009-12-02 18:06 ` Sverre Rabbelier
2009-12-02 18:41 ` Junio C Hamano
2009-12-02 18:50 ` Sverre Rabbelier
2009-12-02 18:52 ` Junio C Hamano
2009-12-02 18:55 ` Sverre Rabbelier
2009-12-02 18:58 ` Junio C Hamano
2009-12-02 19:39 ` Jeff King
2009-12-02 19:25 ` Ilari Liusvaara
2009-12-02 18:07 ` Junio C Hamano
2009-12-02 18:47 ` Ilari Liusvaara
2009-12-02 19:52 ` Ilari Liusvaara
2009-12-02 5:50 ` Ilari Liusvaara
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=20091201192233.GL21299@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=ilari.liusvaara@elisanet.fi \
/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 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 NNTP newsgroup(s).