I have the same issue (I'm using Git Publisher to update a branch when a build is successful).

The problem appears to be here (git-client-plugin/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java):

    public ObjectId getHeadRev(String url, String branch) throws GitException, InterruptedException {
	String[] branchExploded = branch.split("/");
	branch = branchExploded[branchExploded.length-1];
        ....
        args.add(branch);

Only the last path element of branch is provided to the command line, resulting in the behavior the reporter mentions above.

Why not just pass 'branch' to the command line verbatim (-h is already added, so there's no danger of pulling a tag)?

Commit ded4597c seems to be the culprit. It's a big commit and I'm no where near familiar enough with git-client-plugin or IGitAPI to understand why this was done.

The git-client-plugin 1.6.4 and git-plugin 2.0.4 include an improvement for better handling of namespace branches (like develop/master in this example). Could you check if the behavior is any better with those plugin versions than with previous plugin versions?

It just killed our authorization...

hudson.util.IOException2: hudson.plugins.git.GitException: Failed to connect to http://####@#########/###.git using credentials (status = 401)
at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:458)
at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356)
at hudson.scm.SCM.poll(SCM.java:373)
at hudson.model.AbstractProject._poll(AbstractProject.java:1581)
at hudson.model.AbstractProject.poll(AbstractProject.java:1490)
at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:462)
at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:491)
at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:679)

Sorry for that damage. I don't think the change related to namespaces and branches is what caused the authorization change. The transition from 1.6.3 to 1.6.4 also includes an upgrade from an obsolete Apache http Java library to a more current (but slightly different) Apache http library.

• Is your URL really "http" rather than "https"?
• Can you duplicate the same failure with a publicly visible URL (so that it a debugger can be attached to watch it fail)?
• If you're using https, are you using a self-signed certificate?
• Does reverting to git-client-plugin 1.6.3 work for you?
• Are there any other hints you can offer which might suggest how your installation is different than the installations which are working with git-client-plugin 1.6.4?

Is your URL really "http" rather than "https"?

Yes

Can you duplicate the same failure with a publicly visible URL (so that it a debugger can be attached to watch it fail)?

Unfortunately, no - this is a commercial product.

Does reverting to git-client-plugin 1.6.3 work for you?

Yes. Git plugin at 2.0.4 is Ok.

Are there any other hints you can offer which might suggest how your installation is different than the installations which are working with git-client-plugin 1.6.4?

I'm using 'Credentials' - there probably aren't that many Auth + non-HTTPS set-ups out there.

I'll try running a trace on the git conversation next to see if that yields anything interesting.

It appears that 1.6.4 is not sending an Authorization header - this happens in the very first call to /info/refs. Apache is sending back a 401 Authorization Required and the build fails.

In 1.6.3, Authorization is sent in the very first call. Interestingly, this isn't necessarily the case for future calls - it looks like a 401 + resend chat is the norm for subsequent requests (either because no auth is sent, or the auth is apparantly invalid).

So either 1.6.4 needs to sent an Authorization header up-front, or it needs to gracefully handle a 401 response.

I can see a behavior change from 1.6.3 (ok) to 1.6.4 (fails to clone) when connecting to a private bitbucket repository using https. In the bitbucket case, I stored my bitbucket username and password in a Jenkins credential.

I don't see a behavior change from 1.6.3 (ok) to 1.6.4 (ok) when connecting to a private github repository using https. In the github case, I generated an access token and used my user name and that access token from a Jenkins credential.

Refer to JENKINS-22119 for the new bug report which tracks the bitbucket (and other) private repository authentication problem. The bug where we're having this conversation is fixed, and hiding another bug report inside it may confuse others and make it less likely the bug will be fixed.

A pull request from Alexander Link added a new syntax to more precisely specify branches, without breaking compatibility with existing uses. That is available in git-client-plugin 1.10.2 and in git-plugin 2.2.5.