Could you provide more details of the use case(s) where you think this would be useful?

Added in the description: can be useful for example in the Pipeline: multibranch plugin to fetch merge/pull requests usually available under a different namespace (eg on Github/Gitlab).

Would you mind considering this? Pull request available.

+1
Usecase: would allow multibranch pipeline to work with gerrit patchsets . Currently there isnt another alternative available for gerrit patchsets.

eg:
+refs/changes/:refs/remotes/origin/patchset/

Code changed in jenkins
User: Jean-Baptiste Quenot
Path:
src/main/java/jenkins/plugins/git/AbstractGitSCMSource.java
src/main/java/jenkins/plugins/git/GitSCMSource.java
src/main/resources/jenkins/plugins/git/GitSCMSource/config-detail.jelly
src/test/java/jenkins/plugins/git/AbstractGitSCMSourceTest.java
http://jenkins-ci.org/commit/git-plugin/c7809b55c42532afd13d5587076c9cf437167fe3
Log:
Merge pull request #466 from jbq/git_source_advanced_options

JENKINS-40908 GitSCMSource: support custom remote and refspec

Compare: https://github.com/jenkinsci/git-plugin/compare/d2c36cf91698...c7809b55c425

Merged the PR myself after successfully running all tests locally

I'm headed to a funeral out of state currently, so won't have time to express the details of my concern at your decision to merge the PR yourself without allowing time for the maintainer to validate it.

Could you please discuss the situation with danielbeck and rtyler? I'd like you to confirm that your merging the pull request yourself is within the bounds of the community guidelines. I'm fine with that if it is, and I don't have time to review the community guidelines in detail to decide.

It hasn't been a general practice that people I don't recognize have merged changes to the master branch of the git plugin or the git client plugin.

Hi Mark! Sorry to learn that my decision to merge the PR myself has been taken as an offense. In fact I'm a committer of the git plugin of the early days, that's why I have commit rights on this repo. However if you think this is inappropriate and against new guidelines that I am maybe not aware of, feel free to revert the commit and remove me from the committers. My only wish is that the proposed change be reviewed and eventually incorporated into Jenkins. I also noticed that the PR has been upvoted 11 times so I may not be the only one.

Thanks for your understanding!

No offense was taken from your decision to merge the pull request. I don't see any need to remove you from the committers or anything drastic like that.

I was very pleased to see all the upvotes, since that shows people were thinking about the pull request. I didn't recognize any of the users who were upvoting the pull request, nor did I see any comments that any of the upvotes had tested the proposed pull request, so I wasn't sure how much credence I should place on those upvotes.

Are you interested in assisting further with review of git plugin pull requests?

Hi Mark, it looks like I'm forgiven. Great! I'd be happy to assist in reviewing the issues and pull requests. With great pleasure! It's good to be back to Jenkins business!

Best regards, JB Quenot

I'd love to have more help evaluating pull requests. Choose pull requests that you think are interesting to the community and to you.

I evaluate pull requests by

1. Confirm that I can see the problem described in the pull request (before any change from the pull request) - I've generally preferred to show the problem as a job definition in the lts-with-plugins branch of my jenkins docker image so that I can then continue to reuse that job definition in later regression tests
2. Merge the pull request onto a branch on my fork which starts with the current master branch (merge instructions are included in the pull request automatically behind a link)
3. Build the pull request, run its automated tests, and install it into the docker instance where I've verified the problem is visible
4. Run the job which showed the problem and confirm that the problem is now resolved
5. Run other jobs in that test instance to confirm that none of them regressed from the changes, investigate and correct detected failures
6. Review the code changes - reject API incopmatibilities, ask for corrections to changes which are purely white space, etc.
7. Review the test changes - confirm that there are tests and that they test the expected conditions
8. Evaluate if this change needs to be included on the "old" branch (git plugin 2.6.x and git client plugin 1.21.x) - prefer to not include changes on the old branch, since the old branch lacks submodule authentication support and only exists in those cases where a user cannot tolerate the submodule authentication related changes

In order to reduce duplication of effort, it might be good to record in the pull request comments that you've started evaluating the pull request. I'll do the same for pull requests that I'm evaluating.

Included in git plugin 3.1.0 released 4 Mar 2017