Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove misleading error message #1694

Conversation

Regenhardt
Copy link

GitLab is used for internal hosting, which may often use unencrpted http. This error message is misleading, as the process continues and works regardless, and also falsely mentions Github instead of GitLab.

Got a new PC at work. First clone of the GitLab repo I'm working on went like this:

  • run git clone on an http GitLab instance, in my case I ran git clone http://gitlab.company-local-domain.de/group/project LocalRepo-Name
    Note:
    • http, not https
    • GitLab
  • Get the following error message:
    fatal: Unencrypted HTTP is not supported for GitHub. Ensure the repository remote URL is using HTTPS.
  • Get prompted for and enter credentials
  • Get warning about redirecting to .git URL
  • Cloning commences and finishes successfully

GitLab is used for internal hosting, which may often use unencrpted http. This error message is misleading, as the process continues and works regardless, and also falsely mentions Github instead of GitLab.
@goxijana3

This comment was marked as off-topic.

mjcheetham pushed a commit that referenced this pull request Oct 7, 2024
Today, all the custom host providers (Azure Repos, Bitbucket, GitHub,
GitLab) block the use of HTTP (unencrypted) remote URLs and error out.
Only the generic host provider permits HTTP remotes.

From #1694,
we learn that a common use case for self/corporate hosted Git servers is
to use HTTP remotes. Even if this is **_not recommended_**, GCM should
not outright block these.

Instead, we now add an option, `GCM_ALLOW_UNSAFE_REMOTES` or
`credential.allowUnsafeRemotes`, for the user to explicitly set to allow
the use of these unsafe remotes.

For the generic host provider we only print a warning when using HTTP
remotes to reduce the churn for existing users who rely on GCM for HTTP
remotes.
@mjcheetham
Copy link
Collaborator

Thank you for your PR! We have addressed this issue of not being able to use http:// remotes with GitLab with this other PR #1721

@mjcheetham mjcheetham closed this Oct 7, 2024
@Regenhardt
Copy link
Author

That just changes the error message at default settings, but doesn't change the behaviour, does it? The message is then still misleading, as it implies that you have to change a setting and try again, but then still proceeds with the authentication?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants