This will be shown untill started job is completed

It may not be a very helpful work around for you, but I found with my experiments that I was able to start a concurrent build and the git plugin detected its changes, so long as I launched the concurrent build myself, rather than relying on SCM polling to detect the change.

Since there are command line calls and wget calls which can launch a concurrent build, maybe you could detect the changes to the git repository from another program (a shell script, a python program, etc.), then when a git change was detected, launch the build yourself.

For example, I have a job whose job name is "parallel". I can start multiple copies of that job by running the command:

wget http://127.0.0.1:8080/job/parallel/build?delay=0sec

If you were to probe your source master "every so often", then run that command when an actual source change was detected by your probing program, I think you would get the result you want.

That is just a work around, not a real fix, but it would let you experiment further with the idea of concurrent builds, without waiting for a fix from the Jenkins developers.

Update the title to be more descriptive. Has this been verified as being in the git plugin and not a general SCM issue?

This is valid - the git plugin requires access to the workspace for polling, and so can't poll for changes while a build is running. Workarounds include changing to using post-receive hooks, having a parent job that does nothing but poll and if it finds changes, kick off the real build, etc.

general jenkins issue
possible workarounds :

• use a commit hook to trigger a build
• use single branch setting so no workspace is required for polling