On Tue, May 26, 2015 at 03:01:10PM -0700, Stefan Beller wrote:

> +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))
> +                     die("remote error: %s", arg);
> +
> +             if (starts_with(line, "capability:")) {
> +                     strbuf_addstr(&capabilities_string, line + 
> strlen("capability:"));
> +                     strbuf_addch(&capabilities_string, ' ');
> +             }
> +     }

I think this is the reverse case of next_capabilities in the upload-pack
side, so I'll make the reverse suggestion. :) Would it make things nicer
if both v1 and v2 parsed the capabilities into a string_list?

> +     free(server_capabilities);
> +     server_capabilities = xmalloc(capabilities_string.len + 1);
> +     server_capabilities = strbuf_detach(&capabilities_string, NULL);

Is this xmalloc line left over? The strbuf_detach will write over it.

> +     strbuf_release(&capabilities_string);

No need to release if we just detached.

> +int request_capabilities(int out)
> +{
> +     fprintf(stderr, "request_capabilities\n");

Debug cruft, I presume.

> +     // todo: send our capabilities
> +     packet_write(out, "capability:foo");

No C99 comments. But I think this is just a placeholder. :)

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to