Is there any documentation about this feature available?

• How does it work?
• In which cases is there a redirect to the old URL? Everytime?
• How long does this redirect exist?
• Is there a page where all active redirects can be seen?
• ...

Hi, so i tested this with Bitbucket Server 6.4.3 and it seems to work. Nevertheless there is a problem left.

Assume that you moved a repo A from Project X to Y.

It turns out, that you can create an new repository B in X with the name of project A. So the clone URL will have the exact same name as repo A had before moving it to Y and where it is still pointing to. 

The newly created repo B cannot be accessed since the URL is pointing to A.

In my point of view, Bitbucket should not allow to create a repo in X with the name of A OR needs to alter the clone url.

I see this was resolved a couple years ago in version 5.0, but for the life of me I cannot find out how it was resolved, i.e. how do I move a repository to a different project while keeping the old URL? All of my attempts at Googling have only led me to tickets such as these, and I haven't seen anything jump out of me from the official documentation. FWIW, it would be helpful for all resolved "feature suggestion" tickets if they linked to the relevant documentation. 

@Ken @Steven: from where I stand, what you propose is a different thing altogether than what this ticket is about. You basically want to elude the aliasing altogether by creating "true identifiers" from day one, for git clone. So if the repo id is 1 (Stash already assigns incremental repo ids), you're advocating for presenting the clone command as "git clone git@stash.tail-f.com:1.git" or smth like that. I would create an entirely new ticket for that.

Sticking strictly to this ticket's take i.e. á la Github solution (redirection), as a poor-man's workaround, did anyone try symlinking the repos on the file system? If that works fine, you also need some javascript that checks "am I on repo OLD_PROJ/repo/old_repo, which was moved to NEW_PROJ/repo/new_repo? then compile and redirect to the URL" — an extension could inject this javascript.

@Ken: Yes I agree with the requirement that URLs should be unique (as I stated as well) so that they never change even when moving a repo to another project. I was just pointing out that your original example wouldn't work in some situations.

@Steven: yeah, it's necessary to have unique URLs, but sticking the project ID in there to improve the odds certainly isn't the only way to achieve that. Another way would be to stick a random 4-digit number at the beginning or end. Another way would be to default to the normalized repository name, and if there's a conflict, tell the user "this repository ID exists, please choose another ID", without needing to change the web-visible name.

I think it's necessary to have the project name or some other unique name in the URL. For a large organization, trying to keep all repo names unique might be an issue. For organizations that use forks, it may also be desirable to keep the repo name the same. One solution would be to create a unique identifier when the repo is created on Stash but doesn't change when moved. This URL needs to work for GIT operations (clone, fetch, etc) and for references to Stash pages for browsing.

Yes, this is very much a desired feature for us too. Our project structure in Stash has grown extremely messy, but rearranging things would be very intrusive for our developers and automated processes (including Bamboo builds). Lots of stuff would break, so the pain of keeping the bad organizational structure is probably less than the pain of fixing it.

There's really no reason to put the Project code for a repository in its URL - for us, the ideal option would be to make repository names (the "FOO" in "ssh://git@stash.example.local:7999/PROJ/FOO.git") globally unique, remove the project name (the "PROJ" part), and then when repos move projects, they're not broken.

As we have several external configuration files, pointing to a git repo hosted at STASH each movement of a repo by a user results in the need of updating those configuration files ...

So this IS still a much desired feature on our side ... (at least the wish for PERSISTENT Urls ...)

@jhinch twigged me to this issue. This is really git url aliasing, and it probably could be combined with https://jira.atlassian.com/browse/STASH-2468. The repo tool requires project/path/repo.git, and a git url alias engine would accomodate that nicely.

Out of the ~600 repos we have in Stash, I've been asked to move less than 10 in the last 7 months since the feature was released, and not supporting the historical url wasn't a dealbreaker in the slightest. So supporting a git alias for historical reasons is a very small add, to me. Support a git alias for other reasons, like the repo command - that would be very much appreciated. Upvoted and watched! Thanks.

-Kelly Schoenhofen

That's what I meant with "persistent URL" ...

Name changes would be much less problematic for consumers if we could use IDs in all the rest end points.

I wrote this over in https://jira.atlassian.com/browse/STASH-2796 but I think it applies more here:

Although it would be nice to have a historical URL, for us, it is OK to have the move break the old URL, and in fact that is the wanted behavior. For us moving mostly happens as a admin task in early setup, although we sometimes would do a move in an "old" repo. Both ways we do not need nor want the old URL to work.

If others do maybe one way to do this is to have Alias URLs that can be setup by the admin that does something like:

http://mystash.mycompany.com/old-project\myrepo -> http://mystash.mycompany.com/new-project\myrepo

However I think this isn't a good idea as people then going into stash would be looking for the repo in the old-project. Unless by setting up the alias it puts an alias placeholder in the project.

I'd prefer a solution with having a persistent URL for a repo as well - this URL should never change, no matter to which project/user the repo is assigned to.
Beneath this the current project-projectkey-repository-repositoryslug URL for the repo might exist in parallel. Recording the project keys / repository slugs history on changing them - and providing a redirect in that case is a very good idea.

You should consider private/User repositories with this implementation as well ...

This would need to be extended to the API so that we not only provide the project or repository key but the list of previous keys.