Yes, I can still reproduce the same NPE with "Lightweight checkout" enabled using Git Plugin 3.10.0.

1. Our job definition uses a repo URL of the format ssh://git@bitbucket.our.org/~username/repo.git
2. Our job definition specifies the appropriate Jenkins creds for that URL

Maybe that will lead us somewhere?

I used an ssh protocol Bitbucket URL (git@bitbucket.org:markewaite/jenkins-bugs.git) to clone the Pipeline with git plugin 3.10.0 and git plugin 4.0 pre-release without seeing an NPE. I also used ssh://git@bitbucket.org/markewaite/jenkins-bugs.git to check with git plugin 3.10.0. I'm using an ed235519 ssh credential with the Bitbucket repository. Unfortunately, I still can't duplicate the problem you're seeing.

Well isn't that fun... I came back finally to provide you with more info and ... can no longer reproduce this. I guess this can be closed. Thanks for assisting and trying to solve this with me, Mark.

Thanks for checking again. If you find a way to duplicate it, please reopen it with the details.

I was able to reproduce the issue.

Just use a star "*" as the branch pattern. This will result in a NullPointerException.
Maybe you should add this to the "not supported" checks in the GitSCMFileSystem class:

https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/jenkins/plugins/git/GitSCMFileSystem.java#L255 

And if you're on it:
If you leave the branch field empty or use the default "**" the plugin will complain about an invalid refspec:

java.lang.IllegalArgumentException: Invalid refspec refs/heads/**
 at org.eclipse.jgit.transport.RefSpec.checkValid(RefSpec.java:540)
 at org.eclipse.jgit.transport.RefSpec.<init>(RefSpec.java:192)
 at org.eclipse.jgit.transport.RefSpec.<init>(RefSpec.java:227)
 at jenkins.plugins.git.GitSCMFileSystem$BuilderImpl.build(GitSCMFileSystem.java:345)
 at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:197)
 at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:173)
 at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:115)
 at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:69)
 at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:299)
 at hudson.model.ResourceController.execute(ResourceController.java:97)
 at hudson.model.Executor.run(Executor.java:429)
Finished: FAILURE

Maybe this should be added to the not supported cases too.

Thanks hickstein. It seems counterintuitive to me to use a wildcard for a Pipeline job branch name. That will cause the specific Pipeline job to switch between branches as changes arrive on the individual branches. That creates a changelog in the job which is difficult to understand and leads to the JENKINS-19022 XML bloat problem. The multibranch Pipeline job type is designed to automatically create and destroy jobs for each branch in a repository.

Is there a use case that I've missed for wildcard branch names with a Pipeline job?

That's right. It is very counterintuitive. But for people that are not able to use Multibranch Pipelines (huge git repositories, long build times and seperate workspaces for every branch does not work very well) this is the only option. Thanks for pointing me to the issue. That is one problem we are currently facing.

Nevertheless, throwing a NullPointerException is not very intuitive either. A human readable error message (or just a Fallback to heavyweight checkout) might be a better option in my opinion.

EDIT: We use it in conjunction with Bitbucket Server and the "Webhook to Jenkins for Bitbucket Server" Plugin. We can get a deterministic checkout of the related Jenkinsfile this way.

Thanks! I agree wholeheartedly that it is a bug and it is much worse to throw a null pointer exception than to provide the user a clear message.

See https://github.com/jenkinsci/git-plugin/pull/914 for the pull request that resolves it.

The fix prevents the lightweight checkout by declaring that lightweight checkout does not support a branch named '*'. That is correct, since lightweight checkout uses GitSCMFileSystem and GitSCMFileSystem needs an unambiguous commit.