Just want to check that this doesn't have unexpected side effects if carried out sometime after the project has been created and in use.
Clone URLs contain the project key. If any effected repository is used as a submodule, its remote URLS will be broken. Since these remotes must be URLs with server names and are part of commits, it is typically a pain to move, rename servers or do things like this. A complete fix needs a history rewrite (if you want to keep the history intact / rebuildable) which with bigger teams is almost impossible to do.
I am not aware of more side effects, except that users may need to adjust their remotes.
One way to avoid this is to use relative paths for your submodules if they are all in the same project this will prevent the project name from being embedded in the URL. Existing clones would need to have their .git/config files updated to the new URL but at least new clones would work correctly. Perhaps you can also set up some URL rewriting rules on the server to redirect the original URL to the new URL. But if that project name is ever reused that would cause problems.
There was an issue with it either withe the clients or the server, i dont remember right now.
The .gitmodules contains the URL that is used to populate the submodule. This is checked in to the server. When you run git submodule init, that will read the .gitmodules URL and create an entry in your .git/config that is the full URL to the submodule. Using a relative path for your submodule will store the relative path in the .gitmodules. When you init the submodule that relative path is turned into a fully qualified path and stored in .git/config. So any clones on the client side will need to have their submodule URL updated in the .git/config. Any new clones will be correct.
There are a few long outstanding issues on this
You might vote for one of these
It looks like you're new here. Sign in or register to get started.
