patcht7406: avoid failures solely due to timing issues

This fixes a regression test that produces false positives occasionally: https://git-for-windows.visualstudio.com/git/_build/results?buildId=14035&view=logs

Johannes Schindelin (1):
  t7406: avoid failures solely due to timing issues

 t/t7406-submodule-update.sh | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

base-commit: b7bd9486b055c3f967a870311e704e3bb0654e4f
Published-As: https://github.com/gitgitgadget/git/releases/tags/pr-12%2Fdscho%2Fmore-robust-t7406-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-12/dscho/more-robust-t7406-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/12

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Regression tests are automated tests which try to ensure a specific behavior. The idea is: if the test case fails, the behavior indicated in the test case's title regressed.

If a regression test that fails, even occasionally, for any reason other than to indicate the particular regression(s) it tries to catch, it is less useful than when it really only fails when there is a bug in the (non-test) code that needs to be fixed.

In the instance of the test case "submodule update --init --recursive from subdirectory" of the script t7406-submodule-update.sh, the exact output of a recursive clone is compared with a pre-generated one. And this is a racy test because the structure of the submodules only guarantees a *partial* order. The 'none' and the 'rebasing' submodules *can* be cloned in any order, which means that a mismatch with the hard-coded order does not necessarily indicate a bug in the tested code.

See for example: https://git-for-windows.visualstudio.com/git/_build/results?buildId=14035&view=logs

To prevent such false positives from unnecessarily costing time when investigating test failures, let's take the exact order of the lines out of the equation by sorting them before comparing them.

This test script seems not to have any more test cases that try to verify any specific order in which recursive clones process the submodules, therefore this is the only test case that is changed in this manner.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t7406-submodule-update.sh | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:

Thanks. It obviously goes in the right direction to loosen the ordering requirement that fundamentally cannot be met, as the log message cleanly analizes.

Do we know that the write(2)s that show these lines are atomic, or are we merely lucky that we don't see them intermixed in the middle of lines (sbeller cc'ed). I _think_ they are but just wanted to double check.

On Mon, Jul 23, 2018 at 12:14 PM Junio C Hamano <gitster@pobox.com> wrote:

Not just the lines, but the whole message per submodule (i.e. the "Cloning... " lione and its accompanying "done") is one atomic unit. These messages are from processes invoked via run_processes_parallel (in run-command.h), which buffers all output per process.

This test was last touched in c66410ed32a (submodule init: redirect stdout to stderr, 2016-05-02), merged as f2c96ceb57a (Merge branch 'sb/submodule-init', 2016-05-17)

The parallelizing effort was made before that (2335b870fa7 (submodule update: expose parallelism to the user, 2016-02-29) via bdebbeb3346 (Merge branch 'sb/submodule-parallel-update', 2016-04-06)), but did not review existing tests for the newly introduced raciness.

Thanks for the fix! Stefan

Stefan Beller <sbeller@google.com> writes:

Ah, that explains what I was scratching my head about. I somehow thought that the parallel update broke an otherwise working test written back in the serial days, but it seems it was the other way around. The test was simply careless.

Nice to have the two-year old issue fixed.  Thanks, all.

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:

[jc: forwrding to Torsten for <208b2ede-4833-f062-16f2-f35b8a8ce099@web.de>]

On Mon, Jul 23, 2018 at 12:10:24PM -0700, Junio C Hamano wrote:

Yes, thanks for a "fantastic fast fix" and the integration.

I downloaded and tested it OK (under MacOS) this morning.