We're seeing this issue as well. We have polling setting "* * * * *" that polls repo each minute and when you push branch initially, it gets picked up in a minute. But further pushes to the branch will usually be picked up in something like 15-20 minutes which drives us crazy.

This mainly happens when no other work is going on in the repo. If some other branches are changing, then chances that your already pushed branch will be picked up faster than 15-20 minutes are much higher.

This looks like a state sharing + timing bug in Git Plugin. And yes, we also have "/" in branch pattern: `origin/pr/*/merge`.

markewaite I'm not 100% sure where the issue is, but here is roughly what I have set up:

1. Existing setup running Jenkins 2.32.1, Git Client 2.3.0, Git Plugin 3.0.5, GitHub Plugin 1.26.1, GitHub Branch Source Plugin 2.0.3, and a bunch of other, seemingly unrelated plugins installed (apologies that this isn't a minimal setup to reproduce – I don't have enough existing knowledge of setting up Jenkins for that to be a simple task)
2. Create "New Item" with a GitHub Organization project type
3. Set up the repository sources (private GitHub organization, proper credentials).. Despite what the instructions [here](https://wiki.jenkins-ci.org/display/JENKINS/GitHub+Plugin) say, there is no checkbox for "Build when a change is pushed to GitHub"
4. After Saving the repository source, the organization scans, and the relevant repository also scans. During the scan, branches with a slash in them are picked up just fine. Everything gets triggered the first time.
5. Create a new branch in the repo with a slash (for example, `feature/testing-slashes`), make a whitespace change somewhere, and push a commit
6. Observe that this very first push does trigger a test properly.
7. Make another whitespace change to the new branch, and commit and push that change
8. The branch update does not trigger a test.

I can see in the "All logs" that the GitHub webhook is arriving to Jenkins correctly for the update push, but I don't see any indication in the logs of what happens after the webhook is received.

Another thing that I've observed is that if I navigate to the specific repository and then click on "Scan Repository", then click on "Events", I can see a "CREATED" event in response to the original push of the `feature/test-branch`, which successfully triggers the build, but there is no indication of the UPDATED event for the second push. When I update another branch that doesn't have a slash in it, I do see an UPDATED event that does successfully trigger a build.

Hopefully this helps some. Let me know if there's any other info that I can provide (and preferably how to collect the info, since I'm still fairly new to Jenkins).

Thanks!

rknla can you provide more precise details to duplicate your problem? I just confirmed that the Jenkins jobs in my Docker instance correctly respond to the notifyCommit when a commit arrives on a branch whose name contains a "/".

Steps I took while attempting to duplicate the problem:

1. Clone, build, and run the docker instance

     $ git lfs clone https://github.com/MarkEWaite/docker-lfs JENKINS-27332
     $ cd JENKINS-27332
     $ git lfs fetch origin origin/lts-with-plugins
     $ git checkout -b lts-with-plugins -t origin/lts-with-plugins
     $ docker build -t jenkins:JENKINS-27332 .
     $ docker run -i --rm --publish 8080:8080 jenkins:JENKINS-27332
   

2. Connect a web browser to that docker instance (http://localhost:8080)
3. Open the "Bugs - Individual Checks"
4. Click "Poll Now" in the "JENKINS-29796-multi-refspec-ignored-on-poll" job
5. Confirm in the workspace that it performed a checkout of "develop/JENKINS-29796"
6. Commit a change to "develop/JENKINS-29796" in a repo which has a notifyCommit post-receive hook pointed at my Jenkins instance
7. Confirm that the job ran when that notifyCommit hook was received

I'm experiencing similar symptoms to the original post of this issue, leading me to think that the issue is still here in version 3.0.5.

Particularly: Pushing a new branch named `foo/whatever` triggers correctly, but any subsequent pushes to the same branch do not get picked up and triggered.

Branches that don't have slashes in them appear to behave just fine.

Same problem here. Though git-plugin docs mention fast-remote has an issue if you don't have a master branch which I do it does explain that the old method of checking out to a workspace is a workaround which does work for me.

https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-FastRemotePolling