Allow configuration of the display URL for clone instructions
Problem to solve
For cross-site domain scripting security reasons, and to allow for a smooth transition from existing git infrastructure to using GitLab instead... it can be helpful to serve the web interface of GitLab from one url, while serving the actual git services from a different url.
For the most part, this can be accomplished using something like an HAProxy config to direct git requests to one domain while directing other requests to the web interface domain, so we don't necessarily need something as complex as support for multiple GITLAB_HOST domains as requested in #19449 (moved)
However, even if we did set up our HAProxy configuration, the web interface automatically configures the base url in the clone instructions to match the domain the web interface is served from.
If this base url for clone instructions were made configurable in GitLab settings, we could change the display information to the correct url pattern, while still serving the web interface from a different domain.
Further details
For example - the Drupal project currently serves git from git.drupal.org - but for cross-site-scripting security(and other reasons) we serve the web interface for our existing git services from the drupalcode.org domain.
What we would like to do is serve the web interface of GitLab at gitlab.drupalcode.org, but set the base url for displaying clone instructions to git.drupal.org.
The rest of the configuration for handling git vs. web traffic can be handled with an HAProxy config.
The benefit is that it makes migrating to GitLab significantly easier for a project like ours where tens of thousands of clone urls are already in use at our git.drupal.org domain.
Proposal
Add a simple configuration field to the GitLab settings interface that controls the base url as displayed in the automatically generated clone instructions on projects (and anywhere else instructions might be generated)
What does success look like, and how can we measure that?
Success means a smoother migration path for large, established open source projects who want to transition their projects to GitLab.