Michael Haggerty wrote:

> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -772,13 +767,10 @@ static int get_cmd_result(struct imap_store *ctx, 
> struct imap_cmd *tcmd)
>                                  !strcmp("NO", arg) || !strcmp("BYE", arg)) {
>                               if ((resp = parse_response_code(ctx, NULL, 
> cmd)) != RESP_OK)
>                                       return resp;
> -                     } else if (!strcmp("CAPABILITY", arg))
> +                     } else if (!strcmp("CAPABILITY", arg)) {
>                               parse_capability(imap, cmd);
> -                     else if ((arg1 = next_arg(&cmd))) {
> -                             if (!strcmp("EXISTS", arg1))
> -                                     ctx->gen.count = atoi(arg);
> -                             else if (!strcmp("RECENT", arg1))
> -                                     ctx->gen.recent = atoi(arg);
> +                     } else if ((arg1 = next_arg(&cmd))) {
> +                             /* unused */

Neat.  Let me try to understand what was going on here:

When opening a mailbox with the SELECT command, an IMAP server
responds with tagged data indicating how many messages exist and how
many are marked Recent.  But git imap-send never reads mailboxes and
in particular never uses the SELECT command, so there is no need for
us to parse or record such responses.

Out of paranoia we are keeping the parsing for now, but the parsed
response is unused, hence the comment above.

If I've understood correctly so far (a big assumption), I still am not
sure what it would mean if we hit this ((arg1 = next_arg(&cmd))) case.
Does it mean:

 A. The server has gone haywire and given a tagged response where
    one is not allowed, but let's tolerate it because we always have
    done so?  Or

 B. This is a perfectly normal response to some of the commands we
    send, and we have always been deliberately ignoring it because it
    is not important for what imap-send does?

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