As described in https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28821#note_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](https://gitlab.com/gitlab-org/gitlab/-/blob/99d392ae2cf209f887838289463c7ce2b8b5d146/config/routes/git_http.rb#L4) 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.