Hi Peff, On Fri, 1 Mar 2019, Jeff King wrote: > diff --git a/builtin/fetch.c b/builtin/fetch.c > index b620fd54b4..4ba63d5ac6 100644 > --- a/builtin/fetch.c > +++ b/builtin/fetch.c > @@ -1556,7 +1556,9 @@ static int fetch_one(struct remote *remote, int argc, const char **argv, int pru > > sigchain_push_common(unlock_pack_on_signal); > atexit(unlock_pack); > + sigchain_push(SIGPIPE, SIG_IGN); > exit_code = do_fetch(gtransport, &rs); > + sigchain_pop(SIGPIPE); > refspec_clear(&rs); > transport_disconnect(gtransport); > gtransport = NULL; That indeed does the job: https://git.visualstudio.com/git/_build/results?buildId=358 > That said, I actually think it's kind of pointless for git-fetch to use > SIGPIPE at all. The purpose of SIGPIPE is that you can write a naive > program that spews output, and you'll get informed (forcefully) by the > OS if the process consuming your output stops listening. That makes > sense for programs like "git log", whose primary purpose is generating > output. > > But for git-fetch, our primary purpose is receiving data and writing it > to disk. We should be checking all of our write()s already, and SIGPIPE > is just confusing. The only "big" output we generate is the status table > at the end. And even if that is going to a pipe that closes, I don't > think we'd want to fail the whole command (we'd want to finalize any > writes for what we just fetched, clean up after ourselves, etc). > > So I'd actually be fine with just declaring that certain commands (like > fetch) just ignore SIGPIPE entirely. That's a bigger change than I'm comfortable with, so I'd like to go with tge diff you gave above. Do you want to turn these two patches into a proper patch series? Otherwise I can take care of it, probably this Monday or Tuesday. Ciao, Dscho
