SZEDER Gábor <szeder.dev@xxxxxxxxx> writes:
> A third possible fix, which is also in the "we don't care about the
> order of multiple warning messages" camp and has a nice looking
> diffstat, would be something like this:
Hmph, we are running a "git fetch" locally and observing the error
output from both "fetch" and its counterpart "upload-pack", aren't
we? The "fetch" instances that are run with test_must_fail are
expected to stop talking to "upload-pack" by detecting an error and
severe the connection abruptly---depending on the relative timing
between the processes, the other side may try to read and diagnose
"the remote end hung up unexpectedly", no?
I think "grep -v" filtering is an attempt to protect the test from
getting confused by that output, but is it safe not to worry about
it these days?
> diff --git a/t/t5536-fetch-conflicts.sh b/t/t5536-fetch-conflicts.sh
> index 2e42cf3316..91f28c2f78 100755
> --- a/t/t5536-fetch-conflicts.sh
> +++ b/t/t5536-fetch-conflicts.sh
> @@ -18,14 +18,6 @@ setup_repository () {
> )
> }
>
> -verify_stderr () {
> - cat >expected &&
> - # We're not interested in the error
> - # "fatal: The remote end hung up unexpectedly":
> - test_i18ngrep -E '^(fatal|warning):' <error | grep -v 'hung up' >actual | sort &&
> - test_i18ncmp expected actual
> -}
> -
> test_expect_success 'setup' '
> git commit --allow-empty -m "Initial" &&
> git branch branch1 &&
> @@ -48,9 +40,7 @@ test_expect_success 'fetch conflict: config vs. config' '
> "+refs/heads/branch2:refs/remotes/origin/branch1" && (
> cd ccc &&
> test_must_fail git fetch origin 2>error &&
> - verify_stderr <<-\EOF
> - fatal: Cannot fetch both refs/heads/branch1 and refs/heads/branch2 to refs/remotes/origin/branch1
> - EOF
> + test_i18ngrep "fatal: Cannot fetch both refs/heads/branch1 and refs/heads/branch2 to refs/remotes/origin/branch1" error
> )
> '
