The 'Fast remote polling' checkbox for git based jobs means that master now executes a speedy 'git ls-remote ...' command rather than having to have the slave clone and fetch a local repository. (I think)

I've just re-arranged my configuration such that we now have a linux based master and Windows slaves and spent a bunch'o'time trying to puzzle out why the Git SCM Polling log was failing with errors like:

hudson.plugins.git.GitException: Command "git ls-remote -h git@myserver:myproject.git mybranch" returned status code 128:
stdout:
stderr: error: cannot run ssh: No such file or directory
fatal: unable to fork

I think I've tracked this down (by patching + re-compiling the git plugin) to the 'EnvVarMap' that is used by the launchCommandIn method of GitAPI being (it would seem) the environment of the slave node (i.e. the PATH element was chock full of windows paths) yet the git command was actually being executed on the master, a linux box. (tested by removing git from the master and watching the git polling log fail 'unable to find git')

Presumably this is un-intended behaviour, and a hangover from when the git poll used to happen entirely on the slave (assumption)

A successful workaround is to disable the 'Fast remote polling' option from the job configuration.