Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork939
fix(cmd): fixed deadlock when stderr buffer overflow#357
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
fix(cmd): fixed deadlock when stderr buffer overflow#357
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Fixed deadlock when using stderr=PIPE in Popen and Git generates enoughoutput to a pipe such that it blocks waiting for the OS pipe buffer toaccept more data (seehttps://docs.python.org/2/library/subprocess.html#subprocess.Popen.wait)
Thank you very much ! It's quite amazing how long code like this could survive in a library (as old) as GitPython. (It's probably because |
fix(cmd): fixed deadlock when stderr buffer overflow
Currently I believe GitPython does handle process channels correctly. Maybe you have an example of where this is not the case ? Those who control the process directly, may as well call |
I use Git with Git LFS plugin. When clone a repository with the function git.Repo.clone_from, Git LFS outputs to stderr a list of downloaded files and overflow OS pipe buffer. |
Fixed deadlock when using stderr=PIPE in Popen and Git generates enough
output to a pipe such that it blocks waiting for the OS pipe buffer to
accept more data (seehttps://docs.python.org/2/library/subprocess.html#subprocess.Popen.wait)