On Thu, Aug 06, 2015 at 12:55:35AM -0400, Jeff King wrote:

> PS I don't recall the outcome of our last discussion on the "verbose"
>    test function. Here it makes debug output for the "grep" above more
>    readable when it fails. But it also looks weird not to have the
>    matching negative one for the final grep (which could be
>    test_must_fail in this case, but we do not usually apply that to
>    non-git commands). If you would prefer to strip out the "verbose"
>    (from here and the test just below) while squashing, I am OK with
>    that.

Here's a squashable patch for that, in case it is easier (on top of the
previous squash; I am happy to just send a re-rolled patch if you'd
prefer):

diff --git a/t/t5512-ls-remote.sh b/t/t5512-ls-remote.sh
index 7756100..aadaac5 100755
--- a/t/t5512-ls-remote.sh
+++ b/t/t5512-ls-remote.sh
@@ -150,7 +150,7 @@ do
                git config --add $configsection.hiderefs "!refs/tags/magic" &&
                git config --add $configsection.hiderefs refs/tags/magic/one &&
                git ls-remote . >actual &&
-               verbose grep refs/tags/magic/two actual &&
+               grep refs/tags/magic/two actual &&
                ! grep refs/tags/magic/one actual
        '
 
@@ -160,7 +160,7 @@ test_expect_success 'overrides work between mixed 
transfer/upload-pack hideRefs'
        test_config uploadpack.hiderefs refs/tags &&
        test_config transfer.hiderefs "!refs/tags/magic" &&
        git ls-remote . >actual &&
-       verbose grep refs/tags/magic actual
+       grep refs/tags/magic actual
 '
 
 test_done

I think the last discussion did end up with "eh, now that we have -x it
is simpler to just use that". Of course, then I tried to _use_ -x and
found some small niggles.  So here are fixes for those:

  [1/2]: test-lib: turn off "-x" tracing during chain-lint check
  [2/2]: test-lib: disable trace when test is not verbose

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to