Only on HTTPS?
Closed this issue · 11 comments
It seems like only HTTPS is supported and not SSH. When I try to clone via SSH, an unhandled repository is cloned.
In theory it should work with http://, https:// and ssh:// URLs. However, I have to admit that there is no functional test implemented that explicitly checks that (that would require some public ssh account). Can you give a hint on the ssh-URL you are actually using?
ssh://
A typical ssh URL (as suggested by Github) would look like:
git@github.com:seeraven/gitcache.git
which doesn't have the ssh:// prefix, but perfectly acceptable from git POV.
At least this line fails to execute if a submodule is declared in a form git@github.com:<repo> (w/o ssh:// prefix).
@Youw , thanks for the clarification! You are right, there is the scp-like syntax and even ftp:// and the old git:// protocol that were missing. I've rewritten the interpretation of the repository specifications and also added tests for the main protocols (ftp:// and git:// are missing). You'll find the new release on https://github.com/seeraven/gitcache/releases/tag/v1.0.13 . Would be cool to get some feedback on whether it is working for you now, so that I can close the issue.
That was fast, thanks!
I'll give it a try and will let you know later.
Hm, interesting - right now I'm hitting a different issue:
I have a private repo and SSH key setup to access that repo on Github.
My local SSH key is additionally password-protected, and on Windows, where ssh-agent doesn't work of-the-box (and I never tried to setup it) I'm entering the key password during each git operation, include clone, e.g.: git clone git@github.com:<my repo>.git.
With gitcache 0.13 I'm getting:
2024-04-25 19:19:44 Starting Initial clone of git@github.com:<my repo>.git into D:\gitcache\mirrors\github.com\<my repo>.
Cloning into bare repository 'D:\gitcache\mirrors\github.com\<my repo>\git'...
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
2024-04-25 19:19:46 Command 'C:\Program Files\Git\cmd\git.exe clone --progress --mirror git@github.com:<my repo>.git D:\gitcache\mirrors\github.com\<my repo>\git' failed with return code 128. Starting retry 1 of 3.Even though I have .ssh/config setup for github.com.
Would be cool to get some feedback on whether it is working for you now, so that I can close the issue.
Still one case doesn't work, when the submodule is explicitly in git@github.com:<repo> format:
Traceback (most recent call last):
File "gitcache.py", line 51, in <module>
File "git_cache/git_command.py", line 117, in handle_git_command
File "git_cache/commands/submodule_update.py", line 114, in git_submodule_update
IndexError: list index out of range
[1316034] Failed to execute script 'gitcache' due to unhandled exception!
UPD: actually, it seems like #24
With simple case (single submodule, defined as git@github.com:<repo> - all works good.
The repo I'm using it with is propriatary and way more complicated.
Will investigate further.
Wow, thanks for the fast and thorough testing!
Hm, interesting - right now I'm hitting a different issue: I have a private repo and SSH key setup to access that repo on Github. My local SSH key is additionally password-protected, and on Windows, where ssh-agent doesn't work of-the-box (and I never tried to setup it) I'm entering the key password during each git operation, include clone, e.g.:
git clone git@github.com:<my repo>.git. With gitcache 0.13 I'm getting:
I just have checked whether it works on Linux, and entering a password works here. I will check on Windows later, but I suspect that on Windows the git commands are executed differently (to avoid opening a terminal window every time) and no interactive input is possible.
Meanwhile I've created a temporary release with my latest fixes: https://github.com/Youw/gitcache/releases/tag/v1.0.14-pre-youw
Use: https://github.com/seeraven/gitcache/releases/tag/v1.0.14
@niikoo see if you can check in your environment.
So finally I got the release built. It took a while to get the Windows part fulfull the unit and functional tests, but now the fix from @Youw as well as the URL normalization is integrated. With the URL normalization we get the same cache directory in cases where it is the same, e.g., github.com/seeraven/gitcache and github.com/seeraven/gitcache.git/.
@Youw , I haven't forgotten about the stdin on Windows problem but won't be able to investigate it further this weekend. I hope to be able to take a look next week.
That is awsome news, thanks!
but won't be able to investigate it further this weekend
No problem. Thanks for quick response in a first place!
Interractive password prompt on Windows doesn't block me anyway, since my main use-case - CI/build-machines are using ssh agent on Windows too, so all works as expected now.