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