Repository navigation
OSError: [WinError 193] %1 is not a valid Win32 application when commiting LFS-enabled repository on Windows #971
Description
Activity
It looks like
LFSuses 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.
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])@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. :) )
Reacted by Marvin Kastner and David BriscoeInterestingly
dulwichalso 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.
Details
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.
- added a commit that references this issue
on Jan 14, 2022
Hi. I found that GitPython 3.0.5 throw errors when committing to LFS-enabled repository.
Here is error log:
This can be reproduced by following code:
Target repository is LFS-enabled and *.png are tracked.