All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Josh Steadmon <steadmon@google.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Masaya Suzuki <masayasuzuki@google.com>,
	git@vger.kernel.org, peff@peff.net
Subject: Re: [PATCH v2 0/2] Accept error packets in any context
Date: Mon, 14 Jan 2019 17:49:50 -0800	[thread overview]
Message-ID: <20190115014950.GN162110@google.com> (raw)
In-Reply-To: <20190115014348.GM162110@google.com>

Jonathan Nieder wrote:
> Junio C Hamano wrote:

>> In short, are you shooting js/smart-http-detect-remote-error topic
>> down and replacing it with this one?
>>
>> As that topic is not yet in 'next', I am perfectly fine doing that.
>> I just want to make sure that is what you meant, as my reading of
>> [4] was a bit fuzzy.
>
> Josh, looking at that branch, I see:
>
>  remote-curl: die on server-side errors
>
> 	Includes a test illustrating error handling in the ref
> 	advertisement.  Should that be revived as a standalone patch,
> 	without the remote-curl.c change?

In fact, it appears I have that locally:

 commit 7fe6abcd775dbffd919891d5838f8d125e41f160
 Author: Josh Steadmon <steadmon@google.com>
 Date:   Tue Dec 11 16:25:18 2018 -0800

    lib-httpd, t5551: check server-side HTTP errors

    Add an HTTP path to the test server config that returns an ERR pkt-line
    unconditionally. Verify in t5551 that remote-curl properly detects this
    ERR message and aborts.

    Signed-off-by: Josh Steadmon <steadmon@google.com>
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

It's handled fine by the merge 7be333a6362882e8ffceef3de830dbbfafe99995
(Merge branch 'js/smart-http-detect-remote-error' into pu, 2019-01-11),
though.  So I think what is in "pu" is okay, without shooting any series
down.  (Alternatively we can combine them into a single five-patch
series, if the maintainer prefers.)

Thanks,
Jonathan

  reply	other threads:[~2019-01-15  1:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <reply-to=20181127045301.103807-1-masayasuzuki@google.com>
2018-12-29 21:19 ` [PATCH v2 0/2] Accept error packets in any context Masaya Suzuki
2018-12-29 21:19   ` [PATCH v2 1/2] Use packet_reader instead of packet_read_line Masaya Suzuki
2019-01-07 19:01     ` Jonathan Tan
2019-01-07 22:33     ` Josh Steadmon
2019-01-08 23:27       ` Masaya Suzuki
2018-12-29 21:19   ` [PATCH v2 2/2] pack-protocol.txt: accept error packets in any context Masaya Suzuki
2019-01-07 19:41     ` Jonathan Tan
2019-01-07 22:53     ` Josh Steadmon
2019-01-03 23:05   ` [PATCH v2 0/2] Accept " Junio C Hamano
2019-01-04  0:20     ` Masaya Suzuki
2019-01-15  1:43     ` Jonathan Nieder
2019-01-15  1:49       ` Jonathan Nieder [this message]
2019-01-15 18:44         ` Junio C Hamano

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=20190115014950.GN162110@google.com \
    --to=jrnieder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=masayasuzuki@google.com \
    --cc=peff@peff.net \
    --cc=steadmon@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.