Support repository URL format for old Git clients that are not adding .git suffix

As described in gitlab-runner#28821 (comment 810277172) there are still active Git clients that use old URLs of the git+http protocol. And that don't add .git suffix by default.

Therefore, when such Git client would try to clone, for example, https://example.gitlab.com/my/project, the request would fail with an enigmatic error:

error: RPC failed; result=22, HTTP code = 422
fatal: The remote end hung up unexpectedly

Figuring out what is the problem for someone who have never seen the problem before and don't have access to GitLab Workhorse, Rails and Gitaly logs, is nearly impossible.

By adding the .git suffix to the URL, for example https://example.gitlab.com/my/project.git, the request would succeed.

The behavior is caused by the regexp constraint in the routing definition which requires the .git to be present.

Newer versions of Git solve this problem by automatically adding .git to the repository URL. But using a relatively new Git version is not always the option. For example, the version of Git installed on a default CentOS 7 system (which is still popular and supported until June 2024) is Git 1.8.3.1, while the most recent version is 2.34.1.

This creates a very bad experience for a new Git/GitLab user who for any reason uses an older Git version. As not only the clone fail, but it fails with a message that doesn't help at all to determine what was the cause. Finding out that it's the lack of .git suffix in the repository URL is nearly impossible here.

As the Git protocol is supposed to be backward compatible, I think that the URLs like /project/path/git-upload-pack should be supported directly, just like /project/path.git/git-upload-pack or /project/path.git/info/refs?service=git-upload-pack are.

A simple project that reproduces the error in a CI/CD pipeline can be found at https://gitlab.com/tmaczukin-test-projects/test-centos-7-git-against-gitlab.com.

Proposal

The expected behaviour is that git clone https://example.gitlab.com/project/path will work exactly the same as git clone https://example.gitlab.com/project/path.git - no matter whether a new or old version of Git client is used.