Yes, you're right. Unless you're using multiple repositories in a single job, it is probably best to name the repository "origin" so that it will have the typical name provided by git as a default.

It would be better if we could find a way to provide a much better error message than a failure from git rev-parse when the origin field is left empty, but I'm not sure if that failure message would be enough either.

Hello
I started facing this issue after an upgrade from 2.5.0 to 2.5.1. Downgrading to 2.5.0 solved the issue. The problem is still present in 2.5.2 I just tested it.

rlagoue a key change from 2.5.0 to 2.5.1 is that the original clone now honors the refspec (see JENKINS-31393) specified behind the "Advanced" button of the git plugin "Repositories" section. Could you check the refspec listed in that section of your job definition to confirm that it includes the develop branch?

An alternate way to check if that is the problem affecting you is to test drive the pre-release build from pull request 425. That pull request switches back to the 2.5.0 (and before) default of always pulling all references with the initial clone, even if the refspec will then cause later operations to ignore those references.

I believe that 2.5.1 refspec clone behavior is academically more correct than the 2.5.0 behavior, but JENKINS-36507 found at least one case where the academically more correct behavior can't be handled by a valid use of the git plugin (from the Gerrit plugin). So, git plugin 2.5.3 and later will require that users who want the academically more correct behavior must choose that behavior ("Honor refspec on initial clone") from the "Advanced clone behaviours" choice in the "Additional Behaviours".

Hello Mark..
Here is the refspec value by now:

Is there a problem there?

That refspec is correct if the only branch you're using is the develop branch. The original description of this bug report says that the user was attempting to merge from another branch into the develop branch. Your refspec does not provide that other branch, so the source of the merge would not be available if your refspec were the only one used.

You can place multiple refspecs (separated by spaces) into the refspec field, so you can list the two branches in your refspec.

Hello Mark

thank you for your fast reaction. The other branch has been configure in the "additional behaviours"-part. Here is it

The combination of both (the one in my previous comment and this one) used to work until 2.5.1

Do you mean I should specify the "refspec" for the other branch too, if I want the "automatic merging" work in version released after 2.5.1?

Thank you

Yes. The refspec you listed in your repository definition says "copy the contents of the develop branch from the remote repository to the local repository", but then your merge definition says "merge to the master branch in the local repository". Since git plugin 2.5.1 (and 2.5.2) honor the refspec on initial clone, they don't copy the contents of the master branch from the remote repository to the local repository as part of the initial clone.

The prototype 2.5.3 plugin (and 2.5.3 when it releases) will return to the earlier default behavior of ignoring the refspec on initial clone. I don't like that very much, but I can't see a way to satisfy the use cases which depend on the original behavior. without retaining the original "ignore the refspec on initial clone" as the default behavior.

OK. I understand a little better now. So I will wait for the next release, therefore it will not be necessary for me to adapt all my jenkins projects.

Thank you for your time.

Cheers

Fixed issue as described by rlagoue in git plugin 2.5.3, released 30 July 2016