Just hit this as well, the DOS line ending in a commit message was the root cause for me as well.

i have the same issue with git plugin 2.4.4 but in Jenkins 2.6.

[Pipeline] git
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url http://anakin.ux.dsone.3ds.com:10080/gitlab/3ds/wap.git # timeout=10
Fetching upstream changes from http://anakin.ux.dsone.3ds.com:10080/gitlab/3ds/wap.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress http://anakin.ux.dsone.3ds.com:10080/gitlab/3ds/wap.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/release/419^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/release/419^{commit} # timeout=10
Checking out Revision cedc2f2495ca3c22d80e0c82de1727d55697e0bf (refs/remotes/origin/release/419)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f cedc2f2495ca3c22d80e0c82de1727d55697e0bf # timeout=10
 > git branch -a -v --no-abbrev # timeout=10
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
	at java.lang.String.substring(String.java:1931)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.parseBranches(CliGitAPIImpl.java:1825)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getBranches(CliGitAPIImpl.java:1847)
	at hudson.plugins.git.GitAPI.getBranches(GitAPI.java:195)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:1969)
	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1135)
	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109)
	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:83)
	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:73)
	at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:49)
	at hudson.security.ACL.impersonate(ACL.java:213)
	at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:47)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

Could one of your provide detailed instructions to create a repository which includes a DOS line ending in a commit message in such a way that it shows this bug? I'm interested in fixing the bug, but because I can't duplicate the bug, I can't really know if the bug is fixed.

in our case, this seems to be caused by git revert COMMIT - the default message generated by git contains a ^M at the end (ergo the empty line ergo the exception, fix seems obvious tho)

I've been surprised many times by what I thought were obvious fixes which exposed interesting and unexpected side effects when I duplicated the problem, wrote an automated test for the problem, then implemented a fix.

If you're not willing to provide detailed instructions, could you provide a sample repository that I can use as an example of the problem?

To get a repo with a commit message having the DOS line ending, you can do the following:

git init
touch test.txt
git add test.txt
git commit -m "This is the first line^MFollowed by the second line"

To get that ^M character on MAC OS X, I used the key sequence Ctrl+V Ctrl+M. I think this should also work on linux.

That said, I don't have a repo in this state anymore since it was a short lived branch that caused this for me and I just deleted that branch. When I created a new branch with the above method, I am unable to reproduce this since the 'git branch -a -v --no-abbrev # timeout=10' command is not being executed under my current setup. Will update further if I am able to figure out what conditions cause that command to be executed.

I've created the branch JENKINS-34309 on my jenkins-bugs github repository. That branch includes an "ant" script (build.xml) which by default updates a file (build.number) and commits the update with a Ctrl+M embedded in the commit message.

I have a freestyle job polling that repository and that branch and don't see the failure.

I see an earlier reference to a pipeline job. Was your case using a pipeline job as well? If not, what job type were you using?

My case was definitely a pipeline job but so far I am also unable to reproduce this even with a pipeline job.

the error is caused by a trailing ^M in the commit message of the HEAD of an existing branch within the referenced repository, 100% reproducible

My ant skills are clearly lacking. I can't find a way from my Linux based development machine to place a trailing ^M in the commit message. I've tried with shell commands as well.

Any hints? Alternately, zerofudge could you provide a small repository which has the HEAD of one of its existing branches with a trailing ^M?

This bug is also triggered by this Gitlab bug:

https://gitlab.com/gitlab-org/gitlab-ce/issues/14453

The Gitlab bug has been fixed 4 months ago and is in the leatests releases, but since we hadn't updated yet, we were hit by it last week.

If you'd be willing to try a pre-release, pull request 213 has been built and can be downloaded from the pull request builder.

It ran in my multi-platform test environment successfully, reporting no pareseBranches related StringIndexOutOfBoundsException messages in settings where I was previously seeing them.

Thanks for the info. I will talk to our admins about trying your branch. I hope it will be merged soon.

Hi,

We hit the same issue during one of our builds, wanted to add that we were able to downgrade the git client plugin back to 1.8.1 to bypass the issue.
Not sure how to go back and search each commit that happened for a new line.... in our case the culprit commit is not the most recent, so we would need to go back and update ones that happened several commits ago... not sure how to do that yet....

Git client plugin 1.18.1 is quite old. Is there a reason you went backwards that far rather than trying the pre-release mentioned earlier?

Hi Mark,

No special reason, it was the previously installed version, and I had known it was working then (plus the downgrade to previously installed version button was conveniently there).
Also we were against a deadline, and choose to downgrade instead of going through all the commits searching for messages that had newlines, and that second link you posted to download the build from is no longer pointing to an existing artifact...

I downloaded and built the plugin from the master branch. After loading the pre-release plugin into Jenkins plugins, seems to be working fine. Thanks Mark.

Fixed in git client plugin 1.19.7 released 15 Jul 2016

Code changed in jenkins
User: Mark Waite
Path:
src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java
src/test/java/org/jenkinsci/plugins/gitclient/CliGitAPIImplTest.java
http://jenkins-ci.org/commit/git-client-plugin/85e6a0da7559a46442cdc2910461bf57bbc50ea9
Log:
Merge pull request #273 from bmleite/patch-1

Protect against ArrayIndexOutOfBoundsException (related to JENKINS-34309)

Compare: https://github.com/jenkinsci/git-client-plugin/compare/51ec170386bb...85e6a0da7559