clone never completes

[tardis4500]

I have a somewhat large repo which I can clone at the command line in about 6 minutes. Trying the same thing with a simple Python script and GitPython

from git import Repo
Repo.close('url', 'path')

never finishes. I've tried setting GIT_PYTHON_TRACE, but there is no output anywhere.

When I ^C to kill off the process this is the traceback:
Traceback (most recent call last):
File "C:\Users\jsmith\git\giter.py", line 2, in
Repo.clone_from('git@gitserver:EightK_FPGA_backup', 'gitpython')
File "C:\BaRT\Python34\lib\site-packages\gitpython-0.3.6-py3.4.egg\git\repo\base.py", line 844, in clone_from
return cls._clone(Git(os.getcwd()), url, to_path, GitCmdObjectDB, progress,
**kwargs)
File "C:\BaRT\Python34\lib\site-packages\gitpython-0.3.6-py3.4.egg\git\repo\base.py", line 795, in _clone
finalize_process(proc)
File "C:\BaRT\Python34\lib\site-packages\gitpython-0.3.6-py3.4.egg\git\util.py", line 158, in finalize_process
proc.wait()
File "C:\BaRT\Python34\lib\site-packages\gitpython-0.3.6-py3.4.egg\git\cmd.py", line 298, in wait
status = self.proc.wait()
File "C:\BaRT\Python34\lib\subprocess.py", line 1162, in wait
timeout_millis)

[Byron]

I have seen that before in older versions (pre-0.3.6) in case there were massive amounts of output on stdout or stderr. But that issue has long been fixed, and yours seems to be something else.

As I won't be able to replicate this issue as you seem to be dealing with a private repository, I can only ask you to try the same on a linux box/VM. It's just that I wouldn't trust the process management, both on Windows+Python3.4.

In any case, you should be sure to set GIT_PYTHON_TRACE to full. That way, you might see a little more.

[tardis4500]

I can confirm this only happens on Windows. Setting GIT_PYTHON_TRACE to full doesn't provide any more output.

[Byron]

GitPython uses the standard python logging system - if it is not enabled or setup, you will not see anything indeed. There was a time when it printed to stderr, which certainly was easier to use, but less controllable.

Looking at the call-stack, the only thing that's done is a .wait() call on a sub-process, with which git-python has nothing to do with.
What you could do is to try it on Python 2.7 just to see if it's some sort of recently introduced bug in subprocess.

Hope I could help a little bit at least - please close this issue if you agree it's not a gitpython, but a python problem.
Thanks

[Byron]

Something just came to my mind: You could force gitpython to take a different code-path, one that will forcefully communicate with the subprocess and make totally sure that all pipes are empty. Maybe .communicate() in subprocess is broken.
To do that, just pass in a [RemoteProgress](https://github.com/gitpython-developers/GitPython/blob/master/git/util.py#L172) instance to clone_from(...).

[tardis4500]

I'm closing this for now but if I find time I will try to determine where the real issue is.