Re: [PATCH 2/2] t5516/t5601: be less strict about the number of credential warnings

[Jeff King <peff@peff.net>]

On Tue, Nov 01, 2022 at 04:29:31AM +0100, Ævar Arnfjörð Bjarmason wrote:

> > It is unclear as to _why_, but under certain circumstances the warning
> > about credentials being passed as part of the URL seems to be swallowed
> > by the `git remote-https` helper in the Windows jobs of Git's CI builds.
> 
> ..this description dosen't match what the patch is doing, okey, so
> there's a case where the remote helper swallows the warnings, i.e. we'll
> emit fewer than we expected...

So I really didn't revisit this commit much at all, and was just trying
to save Dscho (or Taylor) the work of having to rebase it, if we go with
my patch 1.

IMHO it is OK enough as it is, but if I were writing it from scratch I
probably would have given the rationale that the tests are insiting on a
dumb, sub-optimal behavior. And flakes or inconsistencies aside, they
should be asserting only the presence or absence of the message. And
probably would have left each at "grep" and dropped the test_line_count
totally.

It is not even clear to me that the remote-https is the one being
swallowed (at least, I have not seen an argument or evidence that this
is so; it does seem plausible).

> > @@ -654,7 +654,7 @@ test_expect_success 'push warns or fails when using username:password' '
> >  	test_must_fail git -c transfer.credentialsInUrl=die \
> >  		push $url_userpass 2>err &&
> >  	grep "fatal: $message" err >warnings &&
> > -	test_line_count = 1 warnings
> > +	test_line_count -ge 1 warnings
> >  '
> 
> ...but then why are we modifying these codepaths that have nothing to do
> with invoking the remote helper, i.e. where we die early before we get
> to that?

If you're arguing that we should only do s/= 3/-ge 1/ for the test that
is flaking, I could buy that. Though like I said, I consider the value
here to be focusing the purpose of the tests as much as dealing with the
flake.

I really don't care that much either way, though.

I'd also be fine with a separate test (marked expect_failure) that
checks the number of messages.

> And even if some of this was invoking that remote helper and we were
> modifying it blindly, then presumably the helper swallowing it would
> result in 0 some of the time, so "-ge 1" would be wrong.
> 
> (That's not the case, but it's why I think the patch doesn't make much
> sense).

I thought the point is that the outer program calling the helper would
consistently produce the error, always yielding at least one instance.
The helper one is generally "extra" and undesired.

-Peff