Experiencing similar problems, I have the same errors as described here, ie.

INFO: No credentials available for BASIC 'GIT at CERN'@git.cern.ch:443

having global and domain credentials defined.

Tried it with: Jgit, default git with distro (Scientific linux CERN 6 (basically SL6 / RHEL6), git 1.7.1) and also even locally compiled newest git 1.8.4.1 - nothing works. It works (eg. with .netrc) when used manually from command line on the same account but not working when executed from a Jenkins' job.

Also - version 1.4.0 is not working anymore with .netrc way of providing credentials for auth. (maybe not preferred but at least working...) - so I had to revert git-client plugin to 1.1.2 to make the jobs working again.

Concerning user experience - note that proper way of using credentials are kind of critical for usage of this plugin - for our case (and I guess for many others) the plugin is basically useless without it... Until it is working properly we will have to stick to old version with .netrc.

BTW. If there are some issues with 'credentials/whatever' plugin maybe providing possibility to set user/password directly just for GIT client could be a temporary solution (just to make possible overriding eventual issues introduced by credentials-plugin, of course not as suggested way of usage)...

I believe I'm seeing this problem on Windows and Linux servers. With version 1.3.0 of the git-client plugin, my .netrc/_netrc credentials were used correctly; with 1.4.0 and 1.4.2, authentication fails every time.

please don't mix issues. Lack of support for .netrc is unrelated to originally reported error that is related to JGit. jGit use is still experimental and known for various limitations. I'll try to reproduce

@Alex Support for credentials has been introduced in 2.0-beta, it seems you don't use it.

The "getURLWithCrendentials" method of class CliGitAPIImpl have a problem if we use https and self-signed certificates, because the HttpClient can't resolve Handsake protocol. Maybe we need ignore the certificates.

private String getURLWithCrendentials(URIish u, StandardCredentials cred) {
  ...


  // assert http URL is accessible to avoid git process to hung asking for username
  if ("http".equalsIgnoreCase(scheme) || "https".equalsIgnoreCase(scheme)) {
    HttpClient client = new HttpClient();
    if (uri.getUser() != null && uri.getPass() != null) {
      client.getParams().setAuthenticationPreemptive(true);
      Credentials defaultcreds = new UsernamePasswordCredentials(uri.getUser(), uri.getPass());
      client.getState().setCredentials(AuthScope.ANY, defaultcreds);
    }
  
    ...
  }

  return url;
}

.netrc support has been added in 1.4.4

self signed certificate is another issue, please create a dedicated Jita
Easy to implement using http://svn.apache.org/viewvc/httpcomponents/oac.hc3x/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/EasySSLProtocolSocketFactory.java?view=markup
Feel free to contribute

.Netrc supported by 1.4.4

Upgrading git-client causes that using .netrc stops working also with generic git clients (not only jGit!), I can see this in log from my build jobs, which are using git client available in SLC6 (1.7.1).

I see that some correction for this is available in 1.4.3 (changelog - .netrc) - I have briefly tested this and I am afraid it is still not working for me, failing in the same way as before (so I have downgraded again the plugin back to 1.1.2 to have the system running again...).

Concerning 2.0-beta you mention - not sure which plugin you mean (git-client? credentials?). Basically I use what is available to update directly in Jenkins, I do not see such version of neither of these plugins (only maven plugin was in 2.0beta, currently updated to 2.0). So - for availability of using credentials in git-plugin - should we wait for releasing some particular version of git-plugin, or just wait for clear green light for this (checking git-client plugin's changelog)?

Just upgraded to 1.4.5 (git-client) and git to 2.0 - still having similar problems, a new issue created (probably different cause...).