All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Derrick Stolee <stolee@gmail.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Derrick Stolee <derrickstolee@github.com>,
	Derrick Stolee <dstolee@microsoft.com>
Subject: Re: [PATCH] t1092: use GIT_PROGRESS_DELAY for consistent results
Date: Tue, 25 May 2021 11:41:04 +0900	[thread overview]
Message-ID: <xmqqa6ojilhb.fsf@gitster.g> (raw)
In-Reply-To: <e35b5217-362f-fc4f-7396-08218a9abf63@gmail.com> (Derrick Stolee's message of "Mon, 24 May 2021 16:38:18 -0400")

Derrick Stolee <stolee@gmail.com> writes:

> The test is comparing the same exact Git command just with
> different configurations. Any change to what Git writes to
> stderr should be consistent across these, unless there is
> an explicit reason why it would behave differently across
> these options (for example, saying "You are in a sparse
> checkout" in 'git status').
>
> There are no expectations that stderr is stable across
> versions of Git. These tests don't add friction to developers
> making new features or changing the error messages that appear
> over stderr. It's just that these tests should catch any
> unintended inconsistency across these modes.

If it just happens that an auto-gc gets triggered, and millions of
other similar reasons in the future, will break that expectation,
without running two different vintages of Git.

I agree with Jonathan that it fundamentally is flakey to expect two
invocations of Git will behave exactly the same.  Even repacking a
repository starting from exactly the same state into a single pack
may not produce byte-for-byte identical result due to thread
scheduling.

      parent reply	other threads:[~2021-05-25  2:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-24 19:55 [PATCH] t1092: use GIT_PROGRESS_DELAY for consistent results Derrick Stolee via GitGitGadget
2021-05-24 20:28 ` Jonathan Nieder
2021-05-24 20:38   ` Derrick Stolee
2021-05-24 21:42     ` Taylor Blau
2021-05-24 22:57       ` Ævar Arnfjörð Bjarmason
2021-05-25  0:13         ` Taylor Blau
2021-05-25  0:39           ` Derrick Stolee
2021-05-25  6:32             ` Junio C Hamano
2021-05-25 10:54               ` Derrick Stolee
2021-05-25 20:46                 ` Junio C Hamano
2021-05-25 21:14                   ` Junio C Hamano
2021-05-25 21:49                   ` Taylor Blau
2021-05-25  2:54           ` Junio C Hamano
2021-05-25 15:10             ` Taylor Blau
2021-05-25  7:39           ` Ævar Arnfjörð Bjarmason
2021-05-25  8:06             ` Junio C Hamano
2021-05-25  2:49       ` Junio C Hamano
2021-05-25  2:41     ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqa6ojilhb.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=derrickstolee@github.com \
    --cc=dstolee@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=jrnieder@gmail.com \
    --cc=stolee@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.