For a matrix project, the pre-merge occurs on the parent build, and the resulting merged revision number is passed to the slaves for their builds. However, the slaves are not able to checkout the merged revision because it only exists in the temporary parent clone. In the example below the build is triggered for revision d4c5faa85 on the feature branch xxx/xxx/develop. This feature branch is merged into xxx/master. This is the log for the parent build

Fetching changes from the remote Git repository
> git config remote.xxx.url ssh://repoURLremoved
Pruning obsolete local branches
Fetching upstream changes from ssh://repoURLremoved
> git --version
> git fetch --tags --progress ssh://repoURLremoved +refs/heads/:refs/remotes/xxx/ --prune
> git rev-parse xxx/xxx/develop^

{commit}
Merging Revision d4c5faa8537180c26350fdecebe2d0b3d05c04c5 (xxx/xxx/develop) onto xxx/master using default strategy
> git rev-parse xxx/master^{commit}

> git config core.sparsecheckout
> git checkout -f xxx/master
> git merge d4c5faa8537180c26350fdecebe2d0b3d05c04c5
> git rev-parse HEAD^

{commit}

Seen branch in repository xxx/xxx/develop
Seen branch in repository xxx/master
Seen 4 remote branches
Checking out Revision 3ead3e08dc58524349b8c629a8a0a5775a3edf74 ()
> git config core.sparsecheckout
> git checkout -f 3ead3e08dc58524349b8c629a8a0a5775a3edf74
....

Here is the log for one of the slaves

Fetching changes from the remote Git repository
> git config remote.xxx.url ssh://repoURLremoved
Pruning obsolete local branches
Fetching upstream changes from ssh://repoURLremoved
> git --version
> git fetch --tags --progress ssh://repoURLremoved +refs/heads/:refs/remotes/xxx/ --prune
Checking out Revision 3ead3e08dc58524349b8c629a8a0a5775a3edf74 ()
> git config core.sparsecheckout
> git checkout -f 3ead3e08dc58524349b8c629a8a0a5775a3edf74
FATAL: Could not checkout null with start point 3ead3e08dc58524349b8c629a8a0a5775a3edf74
....

So the slave tries to checkout the temporary commit 3ead3e08d that only exists in the clone for the parent build.

I've looked at the source and I think the problem is in the function determineRevisionToBuild in GitSCM.java. I am willing to spend some time on this, and I think I know how to solve the problem. However, I could use some guidance on testing to ensure I don't introduce a different bug in the process.