Hi,

I have the same problem as well also under windows XP.

Same is happening for me, but on Linux.

Polling occurs on schedule, but no changes are picked up. There seems to be no difference whether it's on a branch or master, as these two jobs show:

Started on Feb 3, 2010 3:01:24 PM
[poll] Last Build : #876
[poll] Last Built Revision: Revision 1931b23f384c5006eaf9f6ce566332432c71787a (origin/master)

Started on Feb 3, 2010 3:06:24 PM
[poll] Last Build : #74
[poll] Last Built Revision: Revision dee124a5b2dcb8c956cc7dcfc7e794ddbdae0dc7 (origin/branch-1.0)

In both cases, there have been new commits throughout the day which aren't being recognised.

Building manually still works as expected.

This is because the pollChanges method contains Computer.currentComputer().getEnvironment() call, which results in an NPE.

In related to this problem, rev.27665 in Hudson core makes Hudson report this NPE in the polling error log.

Fixed in http://github.com/kohsuke/Hudson-GIT-plugin/commit/f92bb2fd650545e740f409824a6ca27fca34c70a but the change needs to be merged.

Private build of the plugin at rev 97277c53b6eaac155e7136114b07a4dfa58bd6f1 attached at http://issues.jenkins-ci.org/secure/attachment/19151/git.hpi

Thank you kohsuke.
Your private build of the plugin really seems to make a difference.
Looks like polling is going as expected.

Code changed in hudson
User: : magnayn
Path:
trunk/hudson/plugins/git/src/main/java/hudson/plugins/git/GitSCM.java
http://jenkins-ci.org/commit/27729
Log:
[FIXED JENKINS-5237] Computer.getComputer() is NPE unless the caller is in the executor thread.
A better way to obtain the environment in this case is just to do so during the remoting call.

Will this be available in a new version of the git plugin soon (post 0.8)?

The ChangeLog looks out of date here:

http://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin