Can I edit a project key in stash without unexpected side effects?

[Barclays Vendor Management]

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.

[Johannes Kilian]

There are a few long outstanding issues on this

• https://jira.atlassian.com/browse/STASH-3751
• https://jira.atlassian.com/browse/STASH-2796

You might vote for one of these

[Mike Friedrich]

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.

[Steven Whitman]

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.

[Mike Friedrich]

There was an issue with it either withe the clients or the server, i dont remember right now.

[Steven Whitman]

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.

[Mike Friedrich]

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.

[Steven Whitman]

Sorry, I misunderstood your previous statement. I agree with you comments.