Can you provide step-by-step instructions to show the problem you are seeing, and what you're expecting to see instead?

I don't understand based on your description if you're describing the value of branch to build (if so, have you reviewed the help on the branch to build field where it provides many different examples of ways to specify the branch or branches to be built) or if you're describing the branch to merge, or something entirely different.

I can make guesses based on the phrases you've used, but we'll spend a lot of time guessing and working back and forth when it would be much better if you provide a series of numbered steps which show the problem when those steps are taken.

It would also help if there are closed issues which you believe are specifically not related that you reference them by name, as in JENKINS-28911 (if that were one of the bugs which you specifically believe is not related to this bug)

I would also help when describing changed behavior if you can identify the plugin version where the change occurred, or the last plugin version where the behavior matched what you wanted.

The first comment in JENKINS-21845 describes exactly the problem (and a workaround which is not applicable for this issue)

Mark, I have updated the ticket accordingly (I hope). Thank you

You say that the first comment in JENKINS-21845 describes the problem exactly, but that the work around is not applicable. The first comment says:

I think you may have a different issue than is described in that posting on the mailing list. The "ambiguous argument" may be due to the absence of a remote name in the call to
"git rev-parse". The failing seems to be

"git rev-parse /developAutoMerge^{commit}"

but I think it should be something like

"git rev-parse origin/developAutoMerge^{commit}"

In the "Advanced" section of the git repository portion of the job definition, you'll find a field labeled "Name". That field needs a value for the merge use case you're attempting. I set mine to "upstream" and "downstream" to remind myself which one should be the destination of the push.

Please explain why that work around is not applicable. For example, why can't you declare your destination branch as "master" and the repository name as "origin"?

I cannot declare my destination branch as such, since it comes down as a generator parameter. The sender uses origin/master (a value accepted by the git plugin in the "SCM" block) and cannot be changed.

Several other branch formats (accepted by the git plugin in the "SCM" block) would fail as well: refs/heads/master, remotes/origin/master, refs/remotes/origin/master.

andreineculau I don't understand your latest comment clearly enough to use it to duplicate the problem you're seeing. Can you provide a set of step by step instructions that will show the problem you're describing?

You said:

The sender uses origin/master (a value accepted by the git plugin in the "SCM" block) and cannot be changed

Does that mean upstream job definition is passing a parameter to a downstream job, and you can't separate the parameters into separate values for repository name and branch name? Or, is there some other meaning in what you said?

Which location accepts "origin/master" in the SCM block that cannot be changed? The branch name (where it could be changed to "master", as far as I know), or the refspec, or something else?

I can't duplicate this issue as reported.