Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OSError: [WinError 193] %1 is not a valid Win32 application when commiting LFS-enabled repository on Windows #971

Open
KichangKim opened this issue Jan 6, 2020 · 4 comments
Labels

Comments

@KichangKim
Copy link

@KichangKim KichangKim commented Jan 6, 2020

Hi. I found that GitPython 3.0.5 throw errors when committing to LFS-enabled repository.

Here is error log:

Traceback (most recent call last):
File "C:\Users\XXXXXXXX\AppData\Local\Programs\Python\Python37\lib\site-packages\git\index\fun.py", line 85, in run_commit_hook
creationflags=PROC_CREATIONFLAGS,)
File "C:\Users\XXXXXXXX\AppData\Local\Programs\Python\Python37\lib\subprocess.py", line 775, in init
restore_signals, start_new_session)
File "C:\Users\XXXXXXXX\AppData\Local\Programs\Python\Python37\lib\subprocess.py", line 1178, in _execute_child
startupinfo)
OSError: [WinError 193] %1 is not a valid Win32 application

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "c:/Users/XXXXXXXX/Downloads/GitPythonTest/test.py", line 7, in
repo.index.commit('AA')
File "C:\Users\XXXXXXXX\AppData\Local\Programs\Python\Python37\lib\site-packages\git\index\base.py",\index\base.py", line 959, in commit
run_commit_hook('post-commit', self)
File "C:\Users\XXXXXXXX\AppData\Local\Programs\Python\Python37\lib\site-packages\git\index\fun.py", line 87, in run_commit_hook
raise HookExecutionError(hp, ex)
git.exc.HookExecutionError: Hook('C:\Users\XXXXXXXX\Downloads\GitPythonTest.git\hooks\post-commit') failed due to: OSError('[WinError 193] %1 is not not a valid Win32 application')
cmdline: C:\Users\XXXXXXXX\Downloads\GitPythonTest.git\hooks\post-commit

This can be reproduced by following code:

import git

repo = git.Repo('.')

repo.git.add(['test.png', '-A'])

repo.index.commit('AA')

Target repository is LFS-enabled and *.png are tracked.

@Byron Byron added the help wanted label Feb 8, 2020
@Byron
Copy link
Member

@Byron Byron commented Feb 8, 2020

It looks like LFS uses post-commit hooks to do its work, is that correct (see C:\Users\XXXXXXXX\Downloads\GitPythonTest.git\hooks\post-commit ). If so, I wonder what has to be done to be able to execute it.

Anyone able to reproduce it is invited to figure out how to execute such a hook on windows, PRs to fix this are very welcome.

@1kastner
Copy link

@1kastner 1kastner commented Sep 6, 2020

I have encountered the same problem, identical setup. My workaround is now to directly invoke git through subprocess:

subprocess.Popen(["git", 
    "-C", GIT_ROOT_DIR,
    "commit",
    "-am", MY_GENERATED_MESSAGE])
@doom-goober
Copy link

@doom-goober doom-goober commented Sep 24, 2020

@Byron The following fix works on Windows for me: In file: \git\index\fun.py, run_commit_hook() change this line:
cmd = subprocess.Popen([hp] + list(args),

To this:
cmd = subprocess.Popen(["bash"] + [hp] + list(args),

This makes the git bash script run as "bash someBash" instead of "someBash". On most systems the "bash" is redundant but on Windows "bash" will explicitly execute bash, which fixes the problem on my Windows machine.

I am not sure this is an appropriate solution, but given my limited knowledge of bash on various platforms, it seems to work. What is slightly mysterious is that the other bash scripts (pre-commit, for example) seem to work fine without this fix. The git large file system must be doing something slightly different in post-commit.

If this is acceptable, I would happily submit a fix (or you can submit the fix yourself, and I won't have to clone the repository. :) )

@Byron
Copy link
Member

@Byron Byron commented Sep 24, 2020

Interestingly dulwich also executes hooks like that, even though it's not clear that this works any better than it does here.

It's great to have a workaround for this, and adding it to GitPython should be alright if it only triggers on windows and for this kind of hook. Please feel free to submit a PR.

I am sure there is a very logical explanation to this as well, and probably it would be better to find that instead of going with what might end up looking like a 'hack'. If it never causes problems, that should be alright, and if it does we would have to revert it and search for a proper fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.