Multibranch pipeline is unable to checkout branches discovered by 'Discover other refs'

Jenkins ver 2.176.1. To reproduce the problem:

(1) create multibranch pipeline with 1 Behaviour Discover other refs. Refs should be located OUTSIDE of refs/heads (in my example it was refs/merge-requests/*/merge) so no default git mapping <branch_name> -> refs/heads/<branch_name> could be used implicitly

(2) run branch discovery, job for specific branch would be run with result:

 
Branch indexing
> git rev-parse --is-inside-work-tree # timeout=10
Setting origin to
XXXX
> git config remote.origin.url
XXXX

1. timeout=10
   Fetching origin...
   Fetching upstream changes from origin
   > git --version # timeout=10
   > git config --get remote.origin.url # timeout=10
   > git fetch --tags --force --progress origin +refs/merge-requests/*/merge:refs/remotes/origin/merge-requests/*/merge
   > git rev-parse refs/merge-requests/1/merge^{commit} # timeout=10
   ERROR: Could not determine exact tip revision of merge-request-1; falling back to nondeterministic checkout

Then Jenkins tried to get commit 2 more times but the result is the same.

The culprit is the false assumption in

git rev-parse refs/merge-requests/1/merge^{commit}

invocation that the selected branch would be available directly under refs/* which is not true and even refspec used during fetch confirms that. git rev-parse should be run on local remote tracking branch ref refs/remotes/origin/merge-requests/1/merge, not its server counterpart refs/merge-requests/1/merge.

There is a quick workaround for this: create Specify ref specs which would mirror server branch to client branch 1-to-1, in my example  '+refs/merge-requests/*/merge:refs/merge-requests/*/merge'.
 

Additionally (this is not directly related to the problem above) reading Jenkinsfile stage could be optimized by passing --depth 1 switch to git fetch (only during Jenkinsfile discovery!). We don't have to fech full branch history to be able to read Jenkinsfile from the tip of the branch.