I don't see how we can satisfy the larger community of users who expect polling to behave the way it was described in the original post from Kohsuke (build only when changes are detected) and how you've asked that it behave (build every time polling happens, even if there was no change detected).

If you intend to build on a schedule, even if things have not changed, then couldn't you use the existing scheduled build facility to schedule that build?

Alternately, couldn't you use the "build now" link (or the authenticated version of that which will allow you to launch a build even if no changes are detected)?

Mark,

Thanks for the quick answer.
We'll (have to) check the other alternatives. Thx for advice.

If more users should request the "build anyway" behavior, maybe there's a way to add a config option for this...

I'm another user who would like the feature of building for commits that have already been seen. I use the SkullCandy git workflow on Puppet repositories, and it involves merging from a feature branch successively into DEV, then TEST/QA, then PRODUCTION. Because my changes have already been built when I merged into my DEV branch, when I subsequently merge into QA and then PRODUCTION, the Git plugin will refuse to "build" my code. 

Having a configuration option that says something along the lines of "build even for commits that have already been built against" would be fantastic. 

georgi0, Stephen Connolly has envisioned the preparation needed to eventually allow tags to be built, even if they are pointing to a commit which has already been built. Do you apply a tag when you merge into QA and into PRODUCTION?

Also, can you explain how you're merging into QA and into PRODUCTION without a merge commit?

Thanks Mark, 

Now that was a quick response!

I do not currently add at tag when committing to QA or PROD, but could potentially look into doing it. 

I have found with GIT that if DEV, QA and PROD all have the same history and you merge from a feature branch into all three, you don't get three different merge commits, but one - so they all end up with exactly the same history (again). 

Cheers, 
Nick