This is a follow-up to the conversation at #git-devel Standup today. We encountered the following situation. Our normal clone practice is to use SSH URIs. So, the clone is straightforward with the main (8 year old) repo of the style: git@xxxxxxxxxxxxx:project/repo.git with submodules referenced as: git@xxxxxxxxxxxxx:project/module.git When in SSH mode, clones are simple with --recurse-submodules doing what we want. However, we had to clone on a system where SSH was locked down and we could only use HTTPS. The form of the URIs changed rather radically: https://user@xxxxxxxxxxxxx/project/repo.git which caused the submodule clone not to work. Fortunately, the number of submodules was low, so a manual edit of .gitmodules (with update-index --assume-unchanged) and .git/modules and .git/config was not onerous. However, we should be able to redirect the configuration without having to do that. Our directory references are all relative to the main repo, so those did not have to change. We still use SSH for most work with the repo but needed to get source onto a test system for debugging. I would like to put together a best practice section in Documentation/gitsubmodules.txt on the subject, but really don't think I did this *temporary* change the most effective way. I'm looking for better practices than I used - I'm sure there is at least one. There may be code changes involved, particularly since .gitmodules is tracked and contains the full URI (maybe it should not). One option we also explored was explicitly specifying the URI for each submodule using set-url, which works but it seems like there should be something in clone that redirects the part of the URI relative to the main repo - although that would only work in the special case where the submodules have the same host and project as the main repo. -Randall
