Hey Mark.

Sorry for taking a while to reply. Been experimenting trying to find the root cause of this issue.
After messing around with quite a bit I've been led to believe there's a problem with the GitScm plugin parsing some of the Git history in two of repositories we use.

For the culprit repository I created a new repository with the same levels of permission and copied all the files to it and ran it through the GitScm plugin via a simple pipeline (like the one described above) and it worked just fine.

I'm unsure what else I can do to try to this repository to attempt to get it to accept its data.

Ok markewaite I deleted a whole heap of branches and it appears to have gone away.

I possibly think it's got to do with the branch name being too long and just windows/the plugin failing to deal with a character limit somewhere.

I'm happy for you to cancel this but the issue will still potentially plague other windows users.

Thanks francommit for your diligent efforts to duplicate the problem. I have repositories with many, many branches (some with thousands), so I suspect that the problem is not in the count of branches, but one of those branch names may have exercised a bug in the code.

I'll double check as time allows to see if I can find another way to see the problem.

markewaite the issue came back. Turned out a fullstop in the name of a branch was making it go bananas.
Deleted that branch with the fullstop and the problem went away.

Hopefully you can replicate this yourself.

Cheers.

I also ran into this problem

I had this git option enabled: "Check out to specific local branch", in pipeline: extensions : [[$class: 'LocalBranch']]

I solved the problem by deleting some branches. I'm not sure exactly what was going wrong but some index checking couldn't hurt.

https://github.com/jenkinsci/git-client-plugin/blob/git-client-2.5.0/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L2043

lukelast I'm open to a pull request with one or more tests which show the problem, or even to a description of the specific branch names which cause the problem. I'm hesitant to insert bounds checking for a case that isn't duplicated by a test in the code.

I'm not sure what francommit means as a "fullstop" in a branch name, though I assume he means ASCII 2E. If that's the case, then I don't see how that would cause a problem as a branch name, since '.' (ASCII 2E) is allowed as a character in a branch name.

I could see that could being broken by a newline (or other end of line character) in the branch name. However, if a branch name includes some form of line break character (newline, carriage return, etc.) then it is not a valid git branch name, at least per the definition of the valid characters in the git man page.

I've placed a test in my regression test kit which checks for ASCII 2E in a branch name. The test passes. Unfortunately, that means I still can't duplicate this problem.

lukelast the solution I also came across to fix the problem was deleting multiple branches until it worked.

Thanks to vadivel, I've finally understood the condition. lukelast was correct that bounds checking is what is needed. Sorry for my slow comprehension!

The bounds checking which Luke recommended (along with an automated test) was provided about 3 weeks ago in a merge to the master branch. It will be included in the next release of the git client plugin.

You can test an early build by downloading the latest artifact from the ci.jenkins.io build.

Will be fixed with release of git client plugin 2.6.0

Included in git client plugin 2.6.0, released 27 Oct 2017