From: Eric Sunshine <sunshine@sunshineco.com>
To: Stefan Beller <sbeller@google.com>
Cc: "Git List" <git@vger.kernel.org>,
"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
"Jeff King" <peff@peff.net>, "Junio C Hamano" <gitster@pobox.com>
Subject: Re: [RFC/WIP PATCH 06/11] remote.h: add get_remote_capabilities, request_capabilities
Date: Tue, 26 May 2015 23:25:05 -0400 [thread overview]
Message-ID: <CAPig+cRfJKAQ8Q5PF1VfTAGA1njXAshC0RbnMv9cEp4bH_MN7A@mail.gmail.com> (raw)
In-Reply-To: <1432677675-5118-7-git-send-email-sbeller@google.com>
On Tue, May 26, 2015 at 6:01 PM, Stefan Beller <sbeller@google.com> wrote:
> Instead of calling get_remote_heads as a first command during the
> protocol exchange, we need to have fine grained control over the
> capability negotiation in version 2 of the protocol.
>
> Introduce get_remote_capabilities, which will just listen to
> capabilities of the remote and request_capabilities which will
> tell the selection of capabilities to the remote.
>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
> diff --git a/connect.c b/connect.c
> index c0144d8..bb17618 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -105,8 +105,54 @@ static void annotate_refs_with_symref_info(struct ref *ref)
> string_list_clear(&symref, 0);
> }
>
> +void get_remote_capabilities(int in, char *src_buf, size_t src_len)
> +{
> + struct strbuf capabilities_string = STRBUF_INIT;
> + for (;;) {
> + int len;
> + char *line = packet_buffer;
> + const char *arg;
> +
> + len = packet_read(in, &src_buf, &src_len,
> + packet_buffer, sizeof(packet_buffer),
> + PACKET_READ_GENTLE_ON_EOF |
> + PACKET_READ_CHOMP_NEWLINE);
> + if (len < 0)
> + die_initial_contact(0);
> +
> + if (!len)
> + break;
> +
> + if (len > 4 && skip_prefix(line, "ERR ", &arg))
The 'len > 4' check is needed because there's no guarantee that 'line'
is NUL-terminated. Correct?
> + die("remote error: %s", arg);
> +
> + if (starts_with(line, "capability:")) {
> + strbuf_addstr(&capabilities_string, line + strlen("capability:"));
skip_prefix() maybe?
> + strbuf_addch(&capabilities_string, ' ');
> + }
> + }
> + free(server_capabilities);
> + server_capabilities = xmalloc(capabilities_string.len + 1);
> + server_capabilities = strbuf_detach(&capabilities_string, NULL);
So, you're allocating a buffer for server_capabilities and then
immediately throwing away (leaking) that buffer. Seems fishy.
> + strbuf_release(&capabilities_string);
Not outright incorrect, but you've just detached capabilities_string's
buffer, so releasing it doesn't buy anything.
> +}
> +
> +int request_capabilities(int out)
> +{
> + fprintf(stderr, "request_capabilities\n");
> + // todo: send our capabilities
> + packet_write(out, "capability:foo");
> + packet_flush(out);
> +}
> +
> /*
> - * Read all the refs from the other end
> + * Read all the refs from the other end,
> + * in is a file descriptor input stream
> + * src_buf and src_len may be an alternative way to specify the input.
The bit about src_buf and src_len conveys little or nothing. After
reading it, I'm as clueless to their purpose as I would be if they
were undocumented.
> + * list is the output of refs
> + * extra_have is a list to store information learned about sha1 the other side has.
> + * shallow_points
'shallow_points' what?
> */
> struct ref **get_remote_heads(int in, char *src_buf, size_t src_len,
> struct ref **list, unsigned int flags,
> diff --git a/remote.h b/remote.h
> index 04e2310..7381ddf 100644
> --- a/remote.h
> +++ b/remote.h
> @@ -146,6 +146,9 @@ int check_ref_type(const struct ref *ref, int flags);
> void free_refs(struct ref *ref);
>
> struct sha1_array;
> +
> +extern void get_remote_capabilities(int in, char *src_buf, size_t src_len);
> +extern int request_capabilities(int out);
> extern struct ref **get_remote_heads(int in, char *src_buf, size_t src_len,
> struct ref **list, unsigned int flags,
> struct sha1_array *extra_have,
> --
> 2.4.1.345.gab207b6.dirty
next prev parent reply other threads:[~2015-05-27 3:25 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-26 22:01 [RFC/WIP PATCH 00/11] Protocol version 2, again! Stefan Beller
2015-05-26 22:01 ` [RFC/WIP PATCH 01/11] upload-pack: make client capability parsing code a separate function Stefan Beller
2015-05-26 22:01 ` [RFC/WIP PATCH 02/11] upload-pack: only accept capabilities on the first "want" line Stefan Beller
2015-05-26 22:17 ` Junio C Hamano
2015-05-26 22:20 ` Stefan Beller
2015-05-26 22:01 ` [RFC/WIP PATCH 03/11] upload-pack: move capabilities out of send_ref Stefan Beller
2015-05-26 22:01 ` [RFC/WIP PATCH 04/11] upload-pack-2: Implement the version 2 of upload-pack Stefan Beller
2015-05-27 2:30 ` Eric Sunshine
2015-05-27 6:35 ` Jeff King
2015-05-27 17:30 ` Eric Sunshine
2015-05-27 20:14 ` Jeff King
2015-05-27 17:40 ` Stefan Beller
2015-05-27 20:34 ` Jeff King
2015-05-27 20:45 ` Stefan Beller
2015-05-27 21:46 ` Jeff King
2015-05-26 22:01 ` [RFC/WIP PATCH 05/11] transport: add infrastructure to support a protocol version number Stefan Beller
2015-05-27 6:39 ` Jeff King
2015-05-27 19:01 ` Stefan Beller
2015-05-27 20:17 ` Jeff King
2015-05-27 19:10 ` Junio C Hamano
2015-05-26 22:01 ` [RFC/WIP PATCH 06/11] remote.h: add get_remote_capabilities, request_capabilities Stefan Beller
2015-05-27 3:25 ` Eric Sunshine [this message]
2015-05-27 6:50 ` Jeff King
2015-05-27 17:19 ` Eric Sunshine
2015-05-27 20:09 ` Jeff King
2015-05-27 6:45 ` Jeff King
2015-05-29 19:39 ` Stefan Beller
2015-05-29 22:08 ` Jeff King
2015-05-26 22:01 ` [RFC/WIP PATCH 07/11] fetch-pack: use the configured transport protocol Stefan Beller
2015-05-26 22:19 ` Junio C Hamano
2015-05-26 22:23 ` Stefan Beller
2015-05-27 6:53 ` Jeff King
2015-05-26 22:01 ` [RFC/WIP PATCH 08/11] transport: connect_setup appends protocol version number Stefan Beller
2015-05-26 22:21 ` Junio C Hamano
2015-05-26 22:31 ` Stefan Beller
2015-05-27 5:09 ` Junio C Hamano
2015-05-27 6:56 ` Jeff King
2015-05-27 3:33 ` Eric Sunshine
2015-05-27 7:02 ` Jeff King
2015-05-26 22:01 ` [RFC/WIP PATCH 09/11] transport: get_refs_via_connect exchanges capabilities before refs Stefan Beller
2015-05-27 5:37 ` Eric Sunshine
2015-05-27 7:06 ` Jeff King
2015-05-26 22:01 ` [RFC/WIP PATCH 10/11] t5544: add a test case for the new protocol Stefan Beller
2015-05-27 5:34 ` Eric Sunshine
2015-05-27 7:12 ` Jeff King
2015-05-26 22:01 ` [RFC/WIP PATCH 11/11] Document protocol version 2 Stefan Beller
2015-05-29 20:35 ` Junio C Hamano
2015-05-29 21:36 ` Stefan Beller
2015-05-29 21:52 ` Junio C Hamano
2015-05-29 22:21 ` Jeff King
2015-06-01 23:14 ` Stefan Beller
2015-06-01 23:40 ` Stefan Beller
2015-06-04 13:18 ` Jeff King
2015-06-04 17:01 ` Junio C Hamano
2015-06-02 17:06 ` Junio C Hamano
2015-05-27 6:18 ` [RFC/WIP PATCH 00/11] Protocol version 2, again! Jeff King
2015-05-27 7:08 ` Jeff King
2015-06-01 17:49 ` Stefan Beller
2015-06-02 10:10 ` Duy Nguyen
2015-06-04 13:09 ` Jeff King
2015-06-04 16:44 ` Stefan Beller
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=CAPig+cRfJKAQ8Q5PF1VfTAGA1njXAshC0RbnMv9cEp4bH_MN7A@mail.gmail.com \
--to=sunshine@sunshineco.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
--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).