Description

KichangKim

opened on Jan 6, 2020

Issue body actions

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.

Reacted by David Briscoe

Activity

1. Byron

   added

   help wanted

   on Feb 8, 2020
2. Byron commented on Feb 8, 2020

   

   Byron

   on Feb 8, 2020

   Member

   More actions

   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.
3. 1kastner commented on Sep 6, 2020

   

   1kastner

   on Sep 6, 2020

   More actions

   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])
   
4. doom-goober commented on Sep 24, 2020

   

   doom-goober

   on Sep 24, 2020

   More actions

   @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 Briscoe
5. Byron commented on Sep 24, 2020

   

   Byron

   on Sep 24, 2020

   Member

   More actions

   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.

   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.
6. idbrii

   added 3 commits that reference this issue on Jan 13, 2022

   Use bash to open extensionless hooks on windows

   This issue will close once commit 8548145 is merged into the 'main' branch.

   8548145

   Use bash to open extensionless hooks on windows

   This issue will close once commit b80efbb is merged into the 'main' branch.

   b80efbb

   Use bash to open extensionless hooks on windows

   This issue will close once commit 7fcef2a is merged into the 'main' branch.

   7fcef2a
7. Byron

   closed this as completedin #1399on Jan 14, 2022
8. Byron

   added a commit that references this issue on Jan 14, 2022

   Use bash to open extensionless hooks on windows

   This issue will close once commit b719e18 is merged into the 'main' branch.

   b719e18

Issue actions