Replaced the gitmodule addresses to use HTTPS instead of SSH #12
Conversation
|
Hi, You can always check out qdpxx nonrecursively and then edit the .git modules file to change submodules URLs to HTTPS prior to executing the git submodules update --init --recursive. Note that the QIO submodule, has submodules of its own which are independent of how qdpxx-s submodules are handled. Best, On July 4, 2016 12:55:10 PM EDT, Jonas Rylund Glesaaen notifications@github.com wrote:
Bálint Joó, Scientific Computing Group, Jefferson Lab |
|
Hello, Maybe one should add a section about this on the README page in that case. I actually am not a user of qdpxx myself, I have mostly been involved through helping less experienced colleagues when they compile, and it is they who run into this problem and have no idea what is going on. On the other hand I guess you could argue that in this case they should simply download the release tarballs and not look to the git repo. Regardless, if they ever end up here for one reason or another, it would be good to give a pointer. I have always been of the opinion that one should pull through https whenever possible, which is also what github recommends. I have installed it on multiple servers by now and I have yet to find one that has problems with https, however ssh seems to pose problems. Of course, this is only my limited experience. Cheers, |
|
There is a really simple workaround for this SSH issue:
Now the machine has a key registered with GitHub. You can now pull all the public git repositories over SSH just fine. This is something that each developer has to do for each machine to build on. But it does not require any changes to any of the repositories. |
|
Sure, I know that you can do that, but most people who clone qdpxx to compile on their system does not have a github account. That is the difference between being a user and a developer. Developers use the SSH address because it makes it easier to cache credentials through SSH key pairs, and sometimes it is necessary due to firewall restrictions on your clusters, and I understand that that is convenient. However, you would think that there are more users than developers out there, so I would naturally assume that the situation of having problems with the SSH far outnumbers the problems encountered with HTTPS. Also, how often do you push to your submodules? If you develop the modules separately from this project you would never need to authenticate in the first place. |
|
Hi All,
From my point of view, the real issue is that of the submodules. We would need
to make sure to ensure that they are all available via HTTPS as well, otherwise you can get
stuck. Until recently we primarily used SSH and I think this worked for all the submodules.
Let me check into this, but it is not a high priority, since anyone can create a github account
and get an SSH key uploaded.
Best,
B
… On Apr 4, 2017, at 3:08 PM, Jonas Rylund Glesaaen ***@***.***> wrote:
Sure, I know that you can do that, but most people who clone qdpxx to compile on their system does not have a github account. That is the difference between being a user and a developer. Developers use the SSH address because it makes it easier to cache credentials through SSH key pairs, and sometimes it is necessary due to firewall restrictions on your clusters, and I understand that that is convenient. However, you would think that there are more users than developers out there, so I would naturally assume that the situation of having problems with the SSH far outnumbers the problems encountered with HTTPS.
Also, how often do you push to your submodules? If you develop the modules separately from this project you would never need to authenticate in the first place.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
--------------------------------------------------------------------------------------
Dr Balint Joo High Performance Computational Scientist
Jefferson Lab
12000 Jefferson Ave, Suite 3, MS 12B2, Room F217,
Newport News, VA 23606, USA
Tel: +1-757-269-5339, Fax: +1-757-269-5427
email: bjoo@jlab.org
-------------------------------------------------------------------------------------
|
|
Hi, I totally agree that it is not a high priority issue, it is mostly that I have had to help multiple coworkers with this issue over the years, and I just wanted to point out that I personally believe it would be more user friendly with https. The permission denied error message you get when you run
is a bit cryptic if you are new to git and just want to download and compile the library. Cheers, |
|
Hi, just to offer another alternative, git supports relative submodule urls: works (fine for us). Depending on how you checked out Regards, Ben |
|
This issue has again hit somebody. The |
I believe that the module paths should be updated from using SSH to use the HTTPS as this has been the github standard for quite a while (see my Issue #8).
I recently tried installing the library on JUQUEEN. I got a:
Permission denied (publickey)error when I did
git submodule update --init --recursiveto pull down the submodules. Updating the gitmodules paths fixes this issue as github has set up the HTTPS protocol for pulling and cloning while SSH is intended for write-access, hence the permission denied.