Better handling of Git 30X responses

Problem to solve

Due to security issue fixes, when using HTTP(S) Git URLs, HTTP redirects won't be followed (Since 12.2). Features impacted by this change:

  • Repository import (by url)
    • Takes quite a long time to get an error message, probably because of the retries in sidekiq.
    • Error message is not really helpful: 13:CreateRepositoryFromURL: clone cmd wait: exit status 128. Please try again.
  • Repository mirroring
    • Error with 301 is showing
    • Related issue: https://gitlab.com/gitlab-com/support-forum/issues/4776

Getting errors can be annoying to the users and unfortunately we don't provide clear instructions what to de when a 30X happens.

Intended users

Mostly Developers.

Proposal

  1. Validate early

When the form is submitted, we could make a HEAD request to the given URL and look for the response code and the Location header. This could be translated into a validation message.

  1. Workaround the .git suffix

Most of the cases the problem originates from the .git suffix. Some SCM expect it, some doesn't. We could try to clone the remote with and without the .git suffix. This would reduce the number of errors considerably.

Initial MR for Gitaly (project imports): gitaly!1467 (closed)

  1. Update the docs (done)

For both forms we provide guidelines where this behaviour is documented, however it's easy to miss. :(

When using the http:// or https:// protocols, please provide the exact URL to the repository. HTTP redirects will not be followed.

What does success look like, and how can we measure that?

Reduced support time, less customer complaints.

Edited Dec 04, 2025 by 🤖 GitLab Bot 🤖
Assignee Loading
Time tracking Loading