From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 0FF691F466 for ; Wed, 15 Jan 2020 19:03:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729080AbgAOTDY (ORCPT ); Wed, 15 Jan 2020 14:03:24 -0500 Received: from cloud.peff.net ([104.130.231.41]:37206 "HELO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1728921AbgAOTDX (ORCPT ); Wed, 15 Jan 2020 14:03:23 -0500 Received: (qmail 18683 invoked by uid 109); 15 Jan 2020 19:03:23 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with SMTP; Wed, 15 Jan 2020 19:03:23 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 32024 invoked by uid 111); 15 Jan 2020 19:09:43 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Wed, 15 Jan 2020 14:09:43 -0500 Authentication-Results: peff.net; auth=none Date: Wed, 15 Jan 2020 14:03:22 -0500 From: Jeff King To: Junio C Hamano Cc: SZEDER =?utf-8?B?R8OhYm9y?= , Johannes Schindelin via GitGitGadget , git@vger.kernel.org, Johannes Schindelin Subject: Re: [PATCH v3 01/10] built-in add -i/-p: treat SIGPIPE as EOF Message-ID: <20200115190322.GA4087422@coredump.intra.peff.net> References: <5e258a8d2bb271433902b2e44c3a30a988bbf512.1578904171.git.gitgitgadget@gmail.com> <20200113170417.GK32750@szeder.dev> <20200113183313.GA2087@coredump.intra.peff.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Wed, Jan 15, 2020 at 10:32:59AM -0800, Junio C Hamano wrote: > >> test_config interactive.diffFilter "cat >/dev/null ; echo too-short" && > >> > >> made the test reliable, with over 2000 --stress repetitions, and that > >> with only a single "y" on 'git add's stdin. > > > > Yeah, I agree the test should be changed. What you wrote above was my > > first thought, too, but I think "sed 1d" is actually a more realistic > > test (and is shorter and one fewer process). > > I am not sure what we are aiming for. Are we making sure the > command behaves well in the hands of end users, who may write a > script that consumes only early parts of the input that is needed > for its use and stops reading, or are we just aiming to claim "all > our tests pass"? I was hoping that we would be doing the former, > and I would understand if the suggestion were "sed 1q" for that > exact reason. > > IOW, shouldn't we be fixing the part that drives the external > process, so that the test "passes" even with such a "broken" filter? The original motivation for this test (and the code that fixes it) was diff-so-fancy, which read all of the input but didn't have a 1:1 line correspondence in the output (IIRC it condensed some particular lines, like rename from/to into a single line). And I think most sane filters would end up reading all of the content. Or a misconfiguration would cause them to read nothing at all. So something like "sed 1d" is more representative of a real filter. If we want to test SIGPIPE, then the current one that reads _nothing_ is the most torturous. But "sed 1q" is neither realistic (if that's what we're going for) nor the hardest thing we can throw at the code (if that's what we want). > > I've been tempted to say that we should just ignore SIGPIPE everywhere, > > and convert even copious-output programs like git-log to just check for > > errors (they could probably even just check ferror(stdout) for each > > commit we output, if we didn't want to touch every printf call). > > Yeah, I share that temptation. Hmm. My recollection was that you were more of a fan of SIGPIPE than I am. But if you agree, then maybe the time has come for action. :) -Peff