Repository navigation
Using gitpython on windows outside git bash raises an exception #26
Description
Activity
You can now use a GIT_PYTHON_GIT_EXECUTABLE environment variable to specify which executable to use. Doing anything windows specific is not the right way, in the end git-python expects git to be in the path. If this is not the case though, the user may now specify where to find git specifically.
This is the excerpt from the docs
- GIT_PYTHON_TRACE
- If set to non-0, all executed git commands will be printed to stdout.
- if set to full, the executed git command will be printed along with its output.
- GIT_PYTHON_GIT_EXECUTABLE
- If set, it should contain the full path to the git executable, e.g. c:\Program Files (x86)\Git\bin\git.exe on windows or /usr/bin/git on linux.
Reacted by Dmitry Sytkov and Jack Riley- GIT_PYTHON_TRACE
That's nice, but I still think that it's a reasonable request for gitpython to work with the way git works in default windows installation.
What I would need to know is why git.cmd, that is the ./cmd directory, is in your PATH, but not ./bin itself.
In my default installation, ./bin is in the PATH.
Or in other words, can you explain why the case you are talking about is indeed common, so that gitpython should support it ?
Currently your issue seems like a special case to me, which is why I am hesitant to do something about it, at least in the way you proposed.Well, I downloaded git for windows from http://git-scm.com/download, and installed it on several windows servers.
In all of them, when choosing you want "git" to work from commandline as well (which I think is the default but am not sure), when I go to cmd immediately after installation and run:
echo %PATH%
I only get the c:\Program Files\Git\cmd directory.
This makes sense, because git.exe won't work from cmd without prior preparations, what git.cmd - the batch file - does.
So for instance, if I have a build script running from a Jenkins slave on my windows hosts, unless I perform some tweaks, it's going to have \cmd in PATH, but not \bin.
AFAIK these are the default settings so I don't think I'm a special case here.
However, if you find the ways I suggested to support this 'ugly', I will understand your being hesitant about them...
I admit the GIT_PYTHON_GIT_EXECUTABLE env var is not such a bad way to go.
What I would recommend - is to at least add this information in the message of the raised exception (instead of a cryptic WindowsError).Reacted by Dmitry SytkovThanks for the detailed description. I now see that in fact, I am the special case :).
Even though I have ./bin in my PATH, I also seem to have ./cmd in the PATH on system level. I don't know who put it there, but I assume it was the installer because I told it to put all linux programs into the system path.Apparently the default option just leaves you with the git.cmd though.
I will have to test whether starting git through a shell (which is cmd.exe in this case) will properly redirect stdin, stdout and stderr to git-python, as it is the case with git.exe.
If this works, I will be glad to put your something like your proposed solution into the cmd implementation.
- added a commit that references this issue
on Mar 29, 2013
Because "git.cmd" is in PATH and not "git"
I wrote an email to mailing list about it.
The exception:
import git
git.Git().help()
WindowsError Traceback (most recent call last)
C:\Program Files\Support Tools in ()
C:\python\lib\site-packages\gitpython-0.3.1-py2.6.egg\git\cmd.pyc in (_args, *kwargs)
217 if name[:1] == '':
218 raise AttributeError(name)
--> 219 return lambda _args, *_kwargs: self._call_process(name, _args, *_kwargs)
220
221 @Property
C:\python\lib\site-packages\gitpython-0.3.1-py2.6.egg\git\cmd.pyc in _call_process(self, method, _args, *_kwargs)
428 call.extend(args)
429
--> 430 return self.execute(call, **_kwargs)
431
432 def _parse_object_header(self, header_line):
C:\python\lib\site-packages\gitpython-0.3.1-py2.6.egg\git\cmd.pyc in execute(self, command, istream, with_keep_cwd, with_extended_output, with_exceptions, as_process, output_stream, *_subprocess_kwargs)
307 stdout=PIPE,
308 close_fds=(os.name=='posix'),# unsupported on linux
--> 309 *_subprocess_kwargs
310 )
311 if as_process:
C:\python\python26.zip\subprocess.py in init(self, args, bufsize, executable, stdin, stdout, stderr, preexec_fn, close_fds, shell, cwd, env, universal_newlines, startupinfo, creationflags)
593 p2cread, p2cwrite,
594 c2pread, c2pwrite,
--> 595 errread, errwrite)
596
597 if mswindows:
C:\python\python26.zip\subprocess.py in _execute_child(self, args, executable, preexec_fn, close_fds, cwd, env, universal_newlines, startupinfo, creationflags, shell, p2cread, p2cwrite, c2pread, c2pwrite, errread, errwrite)
802 env,
803 cwd,
--> 804 startupinfo)
805 except pywintypes.error, e:
806 # Translate pywintypes.error to WindowsError, which is
Fix
Changing line 427 in cmd.py from "git" to "git.cmd" solved this locally.
Need a better solution, e.g.