t7406: avoid failures solely due to timing issues
commit0b7d324ee52a834261f3fcc6d2aa5a644eb2f955
authorJohannes Schindelin <johannes.schindelin@gmx.de>
Mon, 23 Jul 2018 13:39:42 +0000 (23 06:39 -0700)
committerJunio C Hamano <gitster@pobox.com>
Mon, 23 Jul 2018 19:22:55 +0000 (23 12:22 -0700)
tree7ed09f2c3ba8fdd006eb1621b3b7f6a167416600
parentb7bd9486b055c3f967a870311e704e3bb0654e4f
t7406: avoid failures solely due to timing issues

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>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t7406-submodule-update.sh