Re: [PATCH 2/4] upload-pack.c: allow banning certain object filter(s)
- From
Jeff King <peff@peff.net>
- Date
- Jul 15, 2020, 10:55 UTC
- Message-ID
- <20200715105521.GB3262157@coredump.intra.peff.net>
- In-Reply-To
- <20200715100043.GG11341@szeder.dev>
On Wed, Jul 15, 2020 at 12:00:43PM +0200, SZEDER Gábor wrote:
Show 12 quoted lines
> Once upon a time I had a PoC patch to deal with 'git upload-pack' > aborting while 'git fetch' is still send_request()-ing, by catching > the write error to the closed connection and trying read any pending > ERR packets; Christian cleaned it up and submitted it with a proper > commit message in > > https://public-inbox.org/git/20200422163357.27056-1-chriscool@tuxfamily.org/ > > but it haven't been picked up yet. Disappointingly, that patch > doesn't solve these issues... I haven't looked what's going on > (perhaps 'git clone' does something differently than 'git fetch'? no > idea)
I suspect it is that fetch ignores SIGPIPE, but clone does not. So even when we see a 141 exit code from fetch, it is probably generated synthetically from exit(141) after we saw EPIPE. And your patch works there because we have a chance to pump the read-side of the pipe, whereas in git-clone we die immediately via the signal.
Probably git-clone should ignore SIGPIPE during the network transfer portion of the process for the same reasons given in 143588949c (fetch: ignore SIGPIPE during network operation, 2019-03-03).
-Peff