[JENKINS-11547] Jobs trigger continually even though there are no changes due to git repository being "corrupt"

There is a problem with the git polling mechanism which is causing all our jobs to kick themselves off continually. This happens at random times and just fixes itself, but is causing us all sorts of problems due to the large number of builds triggered.

This is an example of the git polling log:

```

Started on 28-Oct-2011 03:20:22
Using strategy: Default
[poll] Last Build : #480
[poll] Last Built Revision: Revision abcb8a2492b390521e0c720f96f66a88eae09f18 (origin/master)
Workspace has a .git repository, but it appears to be corrupt.
No Git repository yet, an initial checkout is required
Done. Took 0.26 sec
Changes found

```

This is caused when a "git rev-parse --verify HEAD" fails for some reason, but there is no logging to help in what might have gone wrong. It looks like the try/catch around the validateRevision line is too simplistic and the cause of the exception should be considered before returning false.

---
Originally reported by james_cookie, imported from: Jobs trigger continually even though there are no changes due to git repository being "corrupt"

• status: Open
  
• priority: Minor
  
• component(s): git-plugin
  
• resolution: Unresolved
  
• votes: 20
  
• watchers: 30
  
• imported: 2025-12-02
  

Raw content of original issue

There is a problem with the git polling mechanism which is causing all our jobs to kick themselves off continually. This happens at random times and just fixes itself, but is causing us all sorts of problems due to the large number of builds triggered.


This is an example of the git polling log:




 

Started on 28-Oct-2011 03:20:22

Using strategy: Default

[poll] Last Build : #480

[poll] Last Built Revision: Revision abcb8a2492b390521e0c720f96f66a88eae09f18 (origin/master)

Workspace has a .git repository, but it appears to be corrupt.

No Git repository yet, an initial checkout is required

Done. Took 0.26 sec

Changes found



 


This is caused when a "git rev-parse --verify HEAD" fails for some reason, but there is no logging to help in what might have gone wrong. It looks like the try/catch around the validateRevision line is too simplistic and the cause of the exception should be considered before returning false.