You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
File "/usr/local/lib/python2.7/site-packages/git/remote.py", line 779, in fetch
res = self._get_fetch_info_from_stderr(proc, progress)
File "/usr/local/lib/python2.7/site-packages/git/remote.py", line 665, in _get_fetch_info_from_stderr
proc.wait(stderr=stderr_text)
File "/usr/local/lib/python2.7/site-packages/git/cmd.py", line 418, in wait
raise GitCommandError(self.args, status, errstr)
git.exc.GitCommandError: Cmd('git') failed due to: exit code(128)
cmdline: git fetch -v origin
stderr: 'fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.'
I make sure I have full permission with remote repository, I also trying:
Are you sure the key in question does not have a passphrase?
I could imagine that anything run from within a TTY is somehow able to use a cached password and/or connect to the ssh-agent, which GitPython by default wouldn't do (unless maybe $SSH_AGENT_PID and $SSH_AUTH_SOCK are passed as well)
I think something that could shed light on the issue is if the script instead executes ssh -v -i <path to keyfile>. That way, you see exactly what ssh tries to do, and why it fails (if it does fail at all).
Thanks for the update!
It's probably a good idea to use absolute directories, yes. I will remember that for the future.
Since the solution was posted here, I am closing this issue.
Please feel free to post another comment or reopen the issue if there is something you think GitPython should do better.
I believe the current working directory of the git program invocations is the .git folder. Thus you can use these directories to construct the path to the key file, or use the correct relative path, such as ../ssh-keys/id-rsa.
Either way, it is something the application has to figure out, and I don't think GitPython can be of any help there.
However, if you believe the documentation could be improved, please feel free to submit a PR with the changes that would have helped you :).
ghost added a commit that references this issue on Jan 17, 2018
Activity
qneill commentedon Oct 18, 2017
Setting GIT_PYTHON_TRACE=full in the environment may shed some light on this. See
http://gitpython.readthedocs.io/en/stable/tutorial.html#git-command-debugging-and-customization
Finish sql file using git to backup
Byron commentedon Dec 11, 2017
Are you sure the key in question does not have a passphrase?
I could imagine that anything run from within a TTY is somehow able to use a cached password and/or connect to the ssh-agent, which GitPython by default wouldn't do (unless maybe
$SSH_AGENT_PIDand$SSH_AUTH_SOCKare passed as well)Byron commentedon Dec 12, 2017
I think something that could shed light on the issue is if the script instead executes
ssh -v -i <path to keyfile>. That way, you see exactly whatsshtries to do, and why it fails (if it does fail at all).Byron commentedon Jan 7, 2018
Thanks for the update!
It's probably a good idea to use absolute directories, yes. I will remember that for the future.
Since the solution was posted here, I am closing this issue.
Please feel free to post another comment or reopen the issue if there is something you think GitPython should do better.
Byron commentedon Jan 8, 2018
I believe the current working directory of the git program invocations is the
.gitfolder. Thus you can use these directories to construct the path to the key file, or use the correct relative path, such as../ssh-keys/id-rsa.Either way, it is something the application has to figure out, and I don't think GitPython can be of any help there.
However, if you believe the documentation could be improved, please feel free to submit a PR with the changes that would have helped you :).
Reconstruction git operation method