-
-
Notifications
You must be signed in to change notification settings - Fork 454
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
[Feature]: Add support for git+ssh #3746
Comments
this is a valid request, but git+ssh was never tested nor advertised as supported. |
By "convert", I guess you mean just change the title, or is there something else I must do? |
that's pretty much it, no need to re-file. |
this is not a git-python or git issue at all and ssh public key is getting read and used.
i've reproduced using |
Issue Description
Hi!
I've got a custom Git configuration which I think is pretty common - working with Github over SSH instead of HTTPS so that I cah authenticate with my SSH key instead of an HTTPS token:
Normally, my SSH identity is added to my SSH agent (
gnome-keyring
), so I can work with Github without even entering my passphrase every time.But when SDNext is running in any session that's not directly spawned by me logged into a GUI, then an SSH agent is not available. So, any Git operation (like updating, installing extensions, or even launching after an update) will fail due to being unable to authenticate over SSH (since any HTTPS links to Github are converted to SSH).
Of course, normally all I'd have many ways to deal with it. Specify
GIT_SSH_COMMAND
environment variable, or set a per-URL identity file in my gitconfig, or set another environment variable to "convert" SSH links back to HTTPS.Unfortunately, none of this works. I've tried anything I could have thought of, and anything multiple LLMs could suggest. For some reason, environment variables present when I launch SDNext do not make it to the actual Git calls. Nor is my SSH config honored. My global .gitconfig seems to be honored, but that's the same config I use for other things (like developing the very same repository), so I don't want to break it.
I've tried hacking around a little - there's not many calls to Git in SDNext. But that didn't help either. There's something mystical going on - it refuses to honor any configuration other than the global .gitconfig . I do have some proof that it should have worked with pure GitPython though.
Steps to reproduce:
Expected results:
Actual results:
Yes, the error message is cryptic, but believe me, if I comment out the HTTPS-to-SSH substitution, it works as expected.
Proof that this is NOT a problem with GitPython:
Problem reproduced. Let's fix it by explicitly specifying an SSH identity file with an environment variable:
Problem solved. This proves that by default, GitPython DOES honor environment variables, even though (I assume) it is not launching Git in a shell session.
Let's fix the problem permanently:
Problem fixed. This proves that GitPython itself also DOES honor the SSH config file. Of course it does, because it's not calling SSH itself - Git calls SSH to establish a connection. So in theory, it should be absolutely impossible to break this, unless you try very very hard and, for example, override the Git SSH command with something that is explicitly told to ignore the default SSH config.
Now try launching SDNext - with GIT_SSH_COMMAND set, with SSH config fixed - problem is still there.
Things I've tried:
This would have been the easiest solution. But I have tried much more - all with the same result: nothing changes.
export GIT_SSH_COMMAND="ssh -o IdentitiesOnly=yes -i ~/.ssh/darkpenguin"
/usr/local/bin/git
with the following content:GIT_SSH_COMMAND="ssh -o IdentitiesOnly=yes -i ~/.ssh/darkpenguin" /usr/bin/git "$@"
git.Repo.clone_from()
in SDNext and adding(env=os.environ)
to its argumentsOf course, the same happens if I try to do any kind of updating.
is there any way at all to fix this without modifying my global .gitconfig? (A local per-project .gitconfig won't help either, because it is not applied when we are cloning a new repository for a new extension, even if we happen to be in a directory that already has another repository cloned.)
Version Platform Description
Relevant log output
Backend
Diffusers
UI
Standard
Branch
Master
Model
Other
Acknowledgements
The text was updated successfully, but these errors were encountered: