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
