I'm not understanding enough of the use case yet (sorry about that). You said, "... only trigger this build when Gerrit sees a change on develop branch..." The refspec you provided (refs/heads/develop) should have only detected changes on the remote branch named "develop". Unfortunately, the refspec you've defined, "refs/heads/develop" seems to mean (with git 2.9.0 on Ubuntu) "fetch the blobs on the remote branch named 'develop', but don't create any local branches to track that remote branch".

Could you try a different experiment? This should fit your use case for both git plugin 2.4.4 and later. Instead of the refspec "ref/heads/develop", use the refspec "ref/heads/develop:refs/remotes/origin/develop". That should cause a remote tracking branch to be created named "origin/develop" which will then satisfy the request for rev-parse origin/develop.

On your earlier question, "can the fix be reverted?", the answer is certainly yes, but then people (like me) in environments with very large repos need to find other solutions, when the git refspec provides a well-designed solution to limit the amount of information fetched from the remote repository.

My earlier suggestion

Another way to retain compatibility with the old "fetch everything initially" behavior would be to require that users who want the fix for JENKINS-31393 must add the "Additional Behaviour" for "Advanced clone behaviours". In that "advanced behaviors" there would be a check box added to "Honor refspec on initial clone". If a large number of users are affected by this same condition, that may be the preferred approach.

is a revert of the fix, with an option for users who want the new behavior to select that new behavior through an optional choice in the "Additional Behaviours"

Before I would add the complexity of the additional checkbox, I'd want to know that many more users are affected by it, or that there is no alternative which will work in cases like yours.

Mark requested:
> Could you try a different experiment?

I should note that because of the Gerrit plugin, I have to specify the refspec as $GERRIT_REFSPEC parameter to the build, and this is sometimes overloaded by the Gerrit plugin when building a verification build, which would then change $GERRIT_REFSPEC to refs/for/<some branch> where it sees a change. I have a check in my build scripting to differentiate between a Gerrit verification build and a build on the branch that this build is watching, in order to prevent attempts to promote verification builds, etc. The integration between Gerrit and Git plugins is poorly done, but that's a different problem.

Using Git plugin 2.4.4, that one does not work either:

12:59:11 > /usr/bin/git init /var/lib/jenkins/workspace/soc-dashboard_dev_nightly # timeout=10
12:59:11 Fetching upstream changes from ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git
12:59:11 > /usr/bin/git --version # timeout=10
12:59:11 > /usr/bin/git -c core.askpass=true fetch --tags --progress ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git +refs/heads/:refs/remotes/origin/
12:59:34 > /usr/bin/git config remote.origin.url ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git # timeout=10
12:59:34 > /usr/bin/git config --add remote.origin.fetch +refs/heads/:refs/remotes/origin/ # timeout=10
12:59:34 > /usr/bin/git config remote.origin.url ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git # timeout=10
12:59:34 Fetching upstream changes from ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git
12:59:34 > /usr/bin/git -c core.askpass=true fetch --tags --progress ssh://jmellor@gerrit.internal:29418/socdash/soc-dashboard.git ref/heads/develop:refs/remotes/origin/develop
12:59:34 ERROR: Error fetching remote repo 'origin'

Thanks for the clarification. It sounds like the only path forward is to make the default behavior of the plugin match the 2.5.0 (and 2.4.4) refspec handling, with an option to honor the refspec in the initial fetch.

I will probably be a week or two before that change is ready and released. You'll know it is in the release when this bug is updated to say that the git plugin release included the change.

Mark asked:
> I'm not understanding enough of the use case yet

When integrating with the Gerrit plugin, it is normally necessary to trigger a "verification" build to check that every commit actually builds and unit-tests. The Gerrit verification builds normally build special refs/for/<branch> branches, which may be merged into the <branch> in git at a future date after code review is complete. In this particular case, <build> is "develop", but gerrit will trigger a build for any branch in the refs/for/* tree as required with the introduction of short-lived feature and bugfix branches. These refs/for branches are deleted by Gerrit upon successful merge to the <branch>, and either a pushbutton build or a merge trigger from Gerrit will trigger the <branch> build.

Make sense now?

jmellor I was able to submit a pull request which I believe meets the use case you have (retain the 2.5.0 and prior behavior of pulling all references on initial clone) while giving users who need the flexibility to honor the refspec in initial clone. For a few days (until the job output expires from the jenkinsci infrastructure), you can download a prototype build.

If it meets your use case, then I'll merge it to the master branch and be able to release it as an official fix for this bug.

After posting that pull request, I performed some more detailed integration testing using a Docker image and many different bug verification jobs. Several of those jobs failed in unexpected ways. Those failures will need to be investigated and resolved before this pull request will be ready to merge to master for a release.

The pull request has been through some additional interactive tests and has been merged to the master branch. A prototype build is available for you to test.

I’ve installed the prototype build, and come up with 4 use-case combinations that test the behaviour change.

I believe that the prototype is working, as all 4 use-cases work as intended. Thumbs up!!!

alt_jmellor thanks very much.

Fixed in git plugin 2.5.3 released 30 July 2016