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.
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.
I now how it works. That was not my point. There was or is a problem with that, it was not working with Stash. All this does not matter for the above question. Relevant is if the project key is part of the sumbodule URL or not, that depends at least on the parents project structure in Stash. Also relevant is that these URLs are part of the git history. Any needed change typically must be done manually on all branches you need/want to maintain. If you want the history (e.g. tagged releases) to still work then you have to rewrite the history. As i said you need to be aware of this because this is really complicated to do.
As a project manager, I have discovered that different developers want to bring their previous branching method with them when they join the team. Some developers are used to performing individual wo...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs