re-enable previously disabled tests with Windows-specific fix

[Byron]

Related to #11821 for which this is a fix.
However, it's probably not yet the optimal solution, depending on how stderr of subprocesses should be handled.

Tasks

• try to fix the issue with an env var.
  • Failure, as one warning remains that seems to originate from a C# HTTP client
• figure out if stderr should be on or off by default - on by default like before, but now one can control it.
• create a new gix release and use it here

Review Notes

• Personally, I think cargo should keep stderr to be inherited so users can see potentially relevant warnings or errors provided by credential helpers. Thus this is still the default, but the tests that need it explicitly disabled stderr of credential helpers.

---

On Windows, gix will call the git-credential-manager, but with stderrset toinheritwhich makes any errors visible to the user, just likegit` does.

1   1         Updating git repository `https://foo.bar/foo/bar`
    2    +warning: auto-detection of host provider took too long (>2000ms)
    3    +warning: see https://aka.ms/gcm/autodetect for more information.
    4    +fatal: A task was canceled.
    5    +warning: auto-detection of host provider took too long (>2000ms)
    6    +warning: see https://aka.ms/gcm/autodetect for more information.`

This, however, isn't what's desirable in tests sometimes, nor may
it be desirable in Cargo.

For now, it seems easiest to disable this particular feature that
issues the warning messages, even though a future gix update
should allow to control what to do with stderr.

[rustbot]

r? @weihanglo

(rustbot has picked a reviewer for you, use r? to override)

[Byron]

@weihanglo This PR is ready for review. Pleas also take a look at the Review Notes, as this issue can definitely be solved in various ways, even though I kept everything as is, while fixing the two tests specifically. Thanks for taking a look.

[weihanglo]

It's unbelievably fast! Thanks for the new release :)

[weihanglo]

@bors r+

[bors]

📌 Commit 49c48b8 has been approved by weihanglo

It is now in the queue for this repository.

[bors]

⌛ Testing commit 49c48b8 with merge 862e53a...

[bors]

☀️ Test successful - checks-actions
Approved by: weihanglo
Pushing 862e53a to master...

[weihanglo]

Looks like we didn't fix the issue 😭.
https://github.com/rust-lang/cargo/actions/runs/7121617635/job/19391179994

I'll disable it again. We can postpone the fix until we're going to stabilize maybe.

[Byron]

Thanks for letting me know.

Experiment: use the new environment variables to see if they work

I did the validation that I probably should have had before, and here is the outcome.

Stderr of external filter programs can now be swallowed as expected:

# .git/config
[filter "noop"]
	clean = "echo clean 1>&2; cat"
	smudge = "echo smudge 1>&2; cat"

# .gitattributes
*.filter filter=noop

delme ( main)
❯ GIX_EXTERNAL_COMMAND_STDERR=false gix rev parse -c :a.filter -b worktree
a

delme ( main)
❯ GIX_EXTERNAL_COMMAND_STDERR=1 gix rev parse -c :a.filter -b worktree
smudge
a

But what matters really is the credential helper:

# .git/config
[credential]
	helper = "!echo error 1>&2"
[remote "origin"]
	url = https://github.com/user/private
	fetch = +refs/heads/*:refs/remotes/origin/*

delme ( main)
❯ GIX_CREDENTIALS_HELPER_STDERR=0 gix fetch
+refs/heads/*:refs/remotes/origin/*
        ed3c7a05308b8201cfa2917a7145acac4f663abb refs/heads/master -> refs/remotes/origin/master [up-to-date]
no negotiation was necessary

delme ( main)
❯ GIX_CREDENTIALS_HELPER_STDERR=1 gix fetch
error store
+refs/heads/*:refs/remotes/origin/*
        ed3c7a05308b8201cfa2917a7145acac4f663abb refs/heads/master -> refs/remotes/origin/master [up-to-date]
no negotiation was necessary

The error store message is being suppressed when the environment variable disables stderr, just as expected.

The wiring actually works, and I double-checked that cargo opens a repository in a way that allows environment variables to be read. So from that point of view it should work.

As the test-suite captures stdout and stderr, this means that the credentials manager also outputs its messages to one of these channels. As stdout is always piped, this means git-credential-manager must send its messages to stderr, which should be disabled. But it is not, which probably means that the envrionment variable isn't going through.

But I validated that by tracing, and any gix Repo that is opened has the correct configuration:

[src/cargo/sources/git/oxide.rs:271] repo.config_snapshot() = [credential]
<tab>helper = /Users/byron/dev/github.com/rust-lang/cargo/target/tmp/cit/t0/script/target/debug/script
[core]
<tab>bare = true
<tab>repositoryformatversion = 0
<tab>filemode = true
<tab>ignorecase = true
<tab>precomposeunicode = true
[gitoxide "http"]
<tab>connectTimeout = 30000
[http]
<tab>lowSpeedLimit = 10
<tab>lowSpeedTime = 30
<tab>userAgent = cargo 1.76.0 (930d6536e 2023-12-06)
[core]
<tab>logAllRefUpdates = false
[gitoxide "credentials"]
<tab>helperStderr = 0 # from GIX_CREDENTIALS_HELPER_STDERR

I even validated that the credential-helper value is false:

[/Users/byron/dev/github.com/Byron/gitoxide/gix/src/config/snapshot/credential_helpers.rs:165] self.try_boolean(Credentials::HELPER_STDERR.logical_name().as_str()).map(|val|
                        Credentials::HELPER_STDERR.enrich_error(val)).transpose().with_leniency(self.repo.options.lenient_config)?.unwrap_or(true) = false

So from all I can tell, it's working as it's supposed to, yet the system-wide credential helper still manages to write to stderr.

Maybe, it writes to the terminal directly, and somehow that ends up being picked up by the test-suite.

Conclusion

So I looked further and decided that the system-wide credential helper shouldn't be picked up in the first place. This is a feature, but the test-suite should be much more isolated.

There are some ways to achieve this, and I think the most practical one is to assure that GIT_CONFIG_NOSYSTEM doesn't pick up the installation-configuration either.

It turns out that GIT_CONFIG_NO_SYSTEM is already set, which means that gix-config needs an adjustment to not include the installation configuration when it is set.