Skip to content
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

Replaced the gitmodule addresses to use HTTPS instead of SSH #12

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

Irubataru
Copy link

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 --recursive

to 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.

@bjoo
Copy link
Contributor

bjoo commented Jul 6, 2016

Hi,
This is tricky for me to decide as some sites support both SSH and HTTPS access and some support SSH only, and some support HTTPS only. So we left them as SSH as that was most convenient for us.

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,
B

On July 4, 2016 12:55:10 PM EDT, Jonas Rylund Glesaaen [email protected] wrote:

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 --recursive

to 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.
You can view, comment on, or merge this pull request online at:

#12

-- Commit Summary --

  • Replaced the gitmodule addresses to use HTTPS instead of SSH

-- File Changes --

M .gitmodules (8)

-- Patch Links --

https://github.com/usqcd-software/qdpxx/pull/12.patch
https://github.com/usqcd-software/qdpxx/pull/12.diff


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#12

Bálint Joó, Scientific Computing Group, Jefferson Lab
Email: [email protected] Tel: +1 757 269 5339
Sent from a mobile device

@Irubataru
Copy link
Author

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,
Jonas

@martin-ueding
Copy link
Contributor

martin-ueding commented Apr 4, 2017

There is a really simple workaround for this SSH issue:

  1. Generate an SSH key pair on the machine that you want to compile on (ssh-keygen ...)
  2. Create some dummy repository on your GitHub account.
  3. Go to the “Settings” of that repository and then to the “Deploy Keys”.
  4. Add the public SSH key from the machine there. You do not need to give push or write permissions.

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.

@Irubataru
Copy link
Author

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.

@bjoo
Copy link
Contributor

bjoo commented Apr 4, 2017 via email

@Irubataru
Copy link
Author

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

git submode update --init --recursive

is a bit cryptic if you are new to git and just want to download and compile the library.

Cheers,
Jonas

@bglaessle
Copy link

Hi,

just to offer another alternative, git supports relative submodule urls:
e.g. for libintrin

    url = ../libintrin.git

works (fine for us). Depending on how you checked out qdp++ ssh or https will be used.

Regards, Ben

@martin-ueding
Copy link
Contributor

This issue has again hit somebody. The git clone --recursive has failed due to the the SSH access. Can we please point those repositories to protocol relative URLs? Then we can have SSH or HTTPS and everyone should be happy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants