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
