git.cmd.Git.execute(..): fix with_stdout=False

[ngie-eign]

In the event the end-user called one of the APIs with with_stdout=False, i.e., they didn't want to capture stdout, the code would crash with an AttributeError or ValueError when trying to dereference the stdout/stderr streams attached to Popen(..) objects.

Be more defensive by checking the streams first to make sure they're not None before trying to access their corresponding attributes.

Add myself to AUTHORS and add corresponding regression tests for the change.

[Byron]

Thanks a lot. This looks good to me.

If the machine doesn't find anything horrendous, we can merge this.

[Copilot]

Pull request overview

Fixes Git.execute(..., with_stdout=False) crashing when stdout/stderr streams are None, and adds regression coverage to prevent future regressions.

Changes:

• Make Git.execute() defensive against None stdout/stderr streams when stripping newlines, copying output, and closing handles.
• Add regression tests for with_stdout=False scenarios (with and without output_stream).
• Add contributor entry to AUTHORS and improve test cleanup robustness in rmtree tests.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
git/cmd.py	Adds None checks around stdout/stderr usage to avoid crashes when stdout isn’t piped.
test/test_git.py	Adds regression tests covering with_stdout=False behavior.
test/test_util.py	Adds a pytest finalizer to ensure temp directories are cleaned up on platforms with stricter permissions.
AUTHORS	Adds a new contributor entry.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Byron]

Needs auto-review comments to be addressed.

[ngie-eign]

@Byron : I tried dealing with the type hinting issues, but it turned into a lot of onion peeling... I would prefer to delay this for another PR (my WIP branch can be found here: https://github.com/ngie-eign/GitPython/tree/type-checking-rabbit-hole ).

[Byron]

Alright, let's do this!

Getting python to be sane at runtime is a bit like fighting windmills. And since CI isn't failing, I suppose we are fine enough until someone raises an issue.

In any case, an overhaul shouldn't be too bad if it leads to actual improvements, but there is also a danger as GitPython is 'stable' with all its faults, which makes it something to rely on. Or in other words: The tests probably don't cover all uses out there and an overhaul can be dangerous.

Maybe before spending too much time on this, you also have a good use case that shows why this is better and why this library really should. Change.