we have a multibranch pipeline job set to build on github Pull Requests with per-merge
(Discover pull requests from origin) and (Merging the pull request with the current target branch revision)

we have advanced clone behaviors 'Fetch tags' checked
'clean after checkout' 'Prune stale remote-tracking branches' and 'wipe out repository & force clone' are all enabled

in the job we are also running some reporting and we want to know the head of pull request (before jenkins merge target branch to it) and the way we are doing that is to run a script that runs

git show -s {BRANCH_NAME}

to get the original commit sha.

I found that during the run jenkins will create a local ref named `remote/origin/PR-XXX` and jenkins will use that as the rev for running the job. and I believe that is done by command like this:

git fetch --tags --progress GIT_REPO_URL +refs/pull/XXX/head:refs/remotes/origin/PR-XXX +refs/heads/master:refs/remotes/origin/master --prune

and in this case the $BRANCH_NAME set by jenkins multibranch pipeline will be `PR-XXX` it creates

so this worked for me at the beginning

but the problem I am having is that sometimes my git show command doesn't return the head of the pull request but rather an old commit of the same pull request, and I was able to login to one of our builders and investigate, it turns out that `git fetch` command above did not actually create the ref `remotes/origin/PR-XXX` correctly.

what's puzzled me even more is that jenkins plugin was able to show the latest commit in its log
e.g. the merge right after the git fetch command will show the correct commit sha
Merging remotes/origin/master commit <MASTER_SHA> into PR head commit <PR_HEAD>
the <PR_HEAD> is the right sha that I want.

so on the builder you see the following state:
at the workspace directory
`git show` will show you all the commits correctly (after merge)
`git show origin/PR-XXX` will show the old outdated pull request head

I ruled out couple of things by poking around:
1. the workspace gets completely wiped out before each run, so it won't be that the ref was there from previous runs, and even if was, the fetch command within the current run should have it updated to latest, besides, some of those runs happened on new builders that never run that PR before.
2. this should not be github server update delay because sometimes we can repro this again in rerun of the job which happens hours after the head of the PR was updated.

and I wasn't able to get a constant repro case on this, only thing I know is that if my PR run fell into that state, I'd have to push another dummy change to fix it, and sometimes I have to push more changes...