I believe the 401 error code in the stack trace indicates that the request was not authorized by the web server. The git-client-plugin 1.6.4 switched from an obsolete version of an http library to a newer supported version of that http library. It also added support the NTLM credentials and for Team Foundation Server git repositories.

If you'd be willing to perform the test, I'd appreciate having you attempt to upgrade just the git-client-plugin, without upgrading git-plugin. If it fails then that will point to changes in git-client-plugin as the most likely cause. If it passes, then it will need to be investigated in both.

Does the https server use a self-signed certificate?

yes, with only git-client upgraded to 1.6.4, git fetch failed.

The server is not using self-signed cert.

yes, with only git-client upgraded to 1.6.4, git fetch failed.

The server is not using self-signed cert.

Thanks. That indicates the problem is likely in the git-client-plugin changes from 1.6.3 to 1.6.4. We'll need you to do deeper investigation to try to narrow the failure modes. Some of the questions which may help narrow the failure modes include:

• Does the problem also appear on a copy of the failing job?
• Does the problem also appear on a newly created job using the same git URL and credentials?
• Does the problem also appear with other https git repositories in your environment?
• Does the problem also appear for you with https git repositories outside your environment? (like github or bitbucket)
• Is there a public URL which can be used to see the same problem?

I can add a bit of information.

Rolling back to 1.6.3 solves the problem.

I get the error pulling from bitbucket, and it fails for every repo I pull from bitbucket.

Posting a link to my earlier (wire) analysis on this (the bug is not directly related, but for me is dependent on getting this issue fixed): JENKINS-20939 12/Mar/14 3:44 AM

It appears that the authentication handshaking has changed since the earlier HTTP library

I finally had some time to dig into this.

What caused the problem for me was that when you copy the https address from a private repository on bitbucket it is displayed as:

https://username@bitbucket.org/username/repo.git

and for a public repo it is:

https://bitbucket.org/username/repo.git

Removing the `username@` from the url in the jenkins setup, fixes the problem for private repos.

A fix that would allow either format would be to strip the username@ from the url in the `checkCredentials()`: https://github.com/jenkinsci/git-client-plugin/blob/master/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L1854

e.g something like this:

diff --git a/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java b/src/main/java/org/jenkins
index 9fd48ab..feb95d2 100644
--- a/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java
+++ b/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java
@@ -1843,6 +1843,7 @@ public class CliGitAPIImpl extends LegacyCompatibleGitAPIImpl {
      */
     private void checkCredentials(URIish u, StandardCredentials cred) {
         String url = u.toPrivateString();
+        url = url.replaceAll("[\\w]+@", "");
         final HttpClientBuilder clientBuilder = HttpClients.custom();
         final CredentialsProvider credentialsProvider = new BasicCredentialsProvider();
         clientBuilder.setDefaultCredentialsProvider(credentialsProvider);

I would expect that change to break several other use cases (like the ssh use case I use to push changes back to a GitHub repository). I think users will need to use the work around for the problem case you described (butbucket https URL's behave better without the username embedded in the URL).

checkCredentials() seems to only deal with HTTP so I can't see how that would affect ssh?

I just found this bug report as my credentials stopped working with my private bitbucket repo. Removing the @username from the url fixed it.

This is quite confusing as this was working before and the behavior of the credentials changed between 1.6.3 and 1.6.4
If the @username can not be stripped, you could perhaps add a hint in the error message telling the user to try without the @username ?

I am facing the same issue not able to connect to repository.
Git client plugin version is 1.10.2 and git plugin 2.2.5

I had restored jenkins using thin backup plugin after formatting the mac. Previously everything was working fine but not its not able to connect.

The call to checkCredentials() has been removed in git-client-plugin from 1.13.1 and beyond. Would you be willing to test a pre-release of git-client-plugin 1.13.1 for this case?

The git-client-plugin 1.14.0 release allows me to fetch and push from a private bitbucket repository using command line git.

I thought I had a problem with GitHub private repository access through https until I read the GitHub documentation which states that https access to a private repository must use a personal access token. Once I generated and used a personal access token in the credential, it worked as expected.