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: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-4.5 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 909581F5AE for ; Tue, 25 May 2021 02:49:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230149AbhEYCvB (ORCPT ); Mon, 24 May 2021 22:51:01 -0400 Received: from pb-smtp1.pobox.com ([64.147.108.70]:60376 "EHLO pb-smtp1.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229718AbhEYCvB (ORCPT ); Mon, 24 May 2021 22:51:01 -0400 Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id F1716CBFF7; Mon, 24 May 2021 22:49:31 -0400 (EDT) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=paxHgXeWMevEJXsA94tYa1kW84ZkcnkXy7ZO0M iiBTg=; b=NDlfP1Nueo0WKlDNgtnqVcU0pYVPWRp3pFf1jXJCcoXIt3oxpMltp2 gjq2CGUPbCwZiAw8ynR/MQmca4NOkOcrXhaipUh7zGPbDJ3A544MNX7KuqUyvLWR fsVOCh0qoa2vMA0tk6VKLIFIygR+1rR5zOwAy8+cYLWxxsYHq45oc= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id E3AA1CBFF6; Mon, 24 May 2021 22:49:31 -0400 (EDT) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.73.10.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 6E8C6CBFF5; Mon, 24 May 2021 22:49:31 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: Taylor Blau Cc: Derrick Stolee , Jonathan Nieder , Derrick Stolee via GitGitGadget , git@vger.kernel.org, Derrick Stolee , Derrick Stolee Subject: Re: [PATCH] t1092: use GIT_PROGRESS_DELAY for consistent results References: Date: Tue, 25 May 2021 11:49:30 +0900 In-Reply-To: (Taylor Blau's message of "Mon, 24 May 2021 17:42:49 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: D49F39FE-BD03-11EB-935E-8B3BC6D8090B-77302942!pb-smtp1.pobox.com Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Taylor Blau writes: > What would perhaps make more sense is to silence the progress meters > from the commands themselves. AFAICT the only command called by > run_on_sparse() which generates a progress meter is 'git checkout', > 'git merge', and 'git submodule', all of which support '--no-progress'. > > Might it be worth passing that option instead of setting > GIT_PROGRESS_DELAY to a large value? Yup. The progress meters are obvious source of variation, but there is no guarantee that is the only source of variation. The test strategy to run the same command twice and judge only by observing their stdout and stderr is, eh, suboptimal. If we devise a sequence of commands that are tested immediately followed by a sequence of commands to check the outcome of these commands, and the output from the latter for two runs are the same, then that is a more sensible approach, as the latter "visualize the outcome of the commands that are just tested" can be controlled more tightly to ignore meaningless variations (like progress meters or base-delta paring in a resulting packfile of a parallel packing) and focus on the aspects of the outcome that matter.