When configuring a project to use git-plugin to poll SCM for changes and using a parameterized build to specify a branch, git-plugin polls the last polled branch instead of the default parameter specified.

1. on any job using a git repository, add a string parameter to represent the branch or tag, say 'deploy_tag', with a default value of 'testing'
2. configure the git repository, replace 'Branch Specifier' with ${deploy_tag}
3. enable 'Poll SCM' and set time period to H/5 * * * *
4. save configuration
5. deploy application / service using the master branch
6. watch git polling log for polling results

Expected behavior:
The polling log would show that the deploy_tag branch was polled.

Actual behavior:
The polling log will indicate that the master branch was polled.

Use case:
I have a client where branches are used to deploy different code to different environments. This allows a developer to deploy code to an environment by merging changes to a specific branch. I would like to be able to always deploy branch X to development automatically while allowing manual deployments to other environments without causing the default deploy scenario to fail. Right now, I have to ensure that I run a manual deploy to development after any manual deploy to staging, production, etc.. or the development build will not trigger a change until the next master commit.