https urls in .gitmodules instead of ssh

[suyashbire1]

git clone --recursive https://github.com/NOAA-GFDL/MOM6-examples.git MOM6-examples

If someone does not have git setup to use SSH, this does not work because it encounters ssh urls in .gitmodules. If all ssh urls are replaced by https ones, the above command works. We can then do away with the Cloning-without-a-GitHub-account page and just replace it with the above command.

Edit: fixed link

[adcroft]

Yes, I think you're right that this could reduce the variations for cloning.

We originally set things up with the git url (ssh transfer protocol) because it allows developers to avoid entering their password for every fetch/pull/push by using ssh-agent (we were then, and probably still are, biased towards the developer's view of things). I'm not aware of a way to avoid repeatedly entering passwords when pushing using the https protocol (at least not a way that our security people would permit). My two cents: applying for a GitHub account is a minor burden and for those not wanting to create a GitHub account then the extra setup commands needed are a one-time requirement. However, we will look at this again.

[suyashbire1]

The ssh protocol continues to work with https urls in .gitmodules. Git is able to parse https urls in ssh format but not the other way around. I have tested this. Can someone else confirm this?

Also, gtools, midas, atmos_null, land_null, mkmf and cv-mix are already in https form.

So this change would come at no additional cost to ssh users. I'm sorry, I should have made it clear in the original message.

[adcroft]

The https URLs (mkmf, atmos_null, MIDAS, ...) are for repositories that MOM6 developers do not all have write access to - hence the mix of URLs in .gitmodules.

I've been trying this out. As far as I can tell, there is no equivalent of "pushUrl" for submodules. The push and pull urls are the same unless you intervene by changing the remote push url after cloning. I am not seeing a way to use https for pulling and ssh for pushing without a whole load of post-clone configuration.

How did you get to the point of "ssh protocol continues to work with https urls in .gitmodules" because it doesn't for me?

[suyashbire1]

Ooops. My bad. Does not work for me either.

How did you get to the point of "ssh protocol continues to work with https urls in .gitmodules" because it doesn't for me?

I just changed the urls in .gitmodules from ssh to https format and forgot to issue a git submodule update command. If I clone into a fresh directory the push command indeed goes through the https protocol instead of ssh. So this would not work.

Another possible solution is to use relative paths in .gitmodules. With relative paths the protocol used in initial cloning is used for subsequent push and pull commands (http://blog.tremily.us/posts/Relative_submodules/). This would carry all the benefits discussed earlier in this thread. However, this would present a problem if someone only wants to fork, say, MOM6-examples because .gitmodules would point to non-existent repos. In such a case we'd need more instructions in the About Github forks section to redirect the relative paths in .gitmodules to NOAA-GFDL.

[adcroft]

This issue has been stewing at the back of my mind. I have come to the conclusion that we should change the .gitmodules to use https and then have developers change the remote for "origin" to use ssh when they set up their work space.

• Most devs setup just once per platform so it's no real burden.
• devs are meant to know what they are doing with git and should not get into trouble.
• Install instructions for setting up for development become much more similar for both privileged developers and non-privileged contributors. As the OP pointed out, the number of choices in the install step are significantly shorten (i.e. shorter wiki pages).
• Bonus: XML based workflow is much simpler!

With the current use of ssh in .gitmodules, it only makes life easier for the privileged devs on rare clones at the expense of complexity for everyone else.